Expand Vitest coverage to include UI modules and reduce broad exclusions

[d-oit]

Summary

The current Vitest coverage config includes only src/**/*.ts, excludes src/features/**, several database-related files, and src/lib/llm/**, and sets thresholds of 70 for lines, functions, branches, and statements.

Problem

The coverage report does not appear to measure most .tsx UI components, and it explicitly excludes the src/features/** area where much of the user-facing behavior is likely implemented. This can create a misleading sense of quality because the reported percentage may stay acceptable even when large parts of the application are untested.

Why this matters

The repository presents itself as a knowledge studio with rich text, graph, mind map, search, and AI-related functionality, so confidence in feature-level behavior matters as much as confidence in shared utilities. A coverage threshold is most useful when it tracks the real product surface rather than a narrow subset of the source tree.

Proposed scope

• Change coverage include patterns from src/**/*.ts to src/**/*.{ts,tsx}.
• Reevaluate the exclusion of src/features/** and keep exclusions only for truly impractical boundaries such as generated code, vendor-like wrappers, or unstable integration seams.
• Keep database or WASM integration files excluded only when there is a clear rationale documented in config comments or contributor docs.
• Review whether a uniform 70 threshold is still appropriate once the measured surface becomes broader.

Acceptance criteria

• Coverage includes both .ts and .tsx files under src.
• Feature modules are covered by default unless explicitly justified.
• Coverage thresholds reflect the actual application surface and not just utility code.
• The test suite still runs reliably in CI and locally.

Suggested implementation notes

• Start by widening the include glob, then shrink the exclusion list one group at a time to avoid a noisy coverage drop all at once.
• If some feature folders are hard to unit test, add targeted component tests or integration-style Vitest tests instead of excluding them permanently.
• Consider publishing coverage as a CI artifact or PR comment so regressions become more visible.

[google-labs-jules]

Jules is on it. When finished, you will see another comment and be able to review a PR.

[google-labs-jules]

Ready for a review! A PR has been created.