[ENHANCEMENT] Add four area-scoped Vitest configs (api, core, services, misc)

[edelauna]

Problem (one or two sentences)

The single vitest.config.ts runs all ~369 area-unit tests in one pass, making it impossible to cache or parallelize coverage by ownership area.

Context (who is affected and when)

Current test file distribution: core/ (117 files), services/ (110), api/ (79), and misc areas — integrations, utils, shared, activate, extension (~63). Each is a stable ownership boundary with few cross-area test dependencies. This is part of the coverage-slicing work tracked in #47 and depends on #114.

Desired behavior (conceptual, not technical)

Four isolated Vitest configs exist (vitest.api.config.ts, vitest.core.config.ts, vitest.services.config.ts, vitest.misc.config.ts), each scoping include to its directory and writing coverage output to coverage/{area}/.

Constraints / preferences (optional)

• Do not modify the existing vitest.config.ts — it must remain functional for local full-suite runs.
• Each area config must be runnable independently: vitest run --config vitest.{area}.config.ts --coverage.
• misc covers: integrations/, utils/, shared/, activate/, extension/.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Acceptance criteria (optional)

• Each of the four configs runs successfully in isolation.
• Each produces a coverage/{area}/lcov.info file.

Proposed approach (optional)

Create four config files mirroring the base vitest.config.ts settings, with include and coverage.include narrowed to the respective directory. Use coverage.reportsDirectory to isolate output per area.

Trade-offs / risks (optional)

If a test file in one area imports source from another area, coverage for that imported code won't appear in the area slice — it will be captured in the merged report only. This is acceptable; the merged report remains the source of truth.

---

Parent issue: #47
Depends on: #114

[zoomote]

Current-main profiling after #1611 changes the recommended scope here. The extension now has 476 test files, and the proposed api / core / services / misc boundaries have substantial cross-area imports; making those cache-safe would require broad or hand-maintained dependency closures, which would either erase the expected cache benefit or risk false cache hits.

Draft PR #1614 takes the smallest dependency-complete first split instead: it keeps all source-unit tests together and separates only src/__tests__/dist_assets.spec.ts, the sole test found to read real dist/ output. The unit coverage lane keeps all default package inputs except that one test and preserves the full report's exact 467 files and 22,823/30,227 covered lines. This issue should remain open but be reframed around profiling-backed source subdivisions only if #117/#118 measurements show the unit lane itself still needs further slicing.

Evidence: post-#1611 cold non-core coverage was ~2m59 on Ubuntu and ~9m40 on Windows; a same-SHA warm run restored it in 1–2s. A forced local bundle is ~40s.