fix(frontend): make the typecheck and coverage gates actually validate

[umzcio]

Summary

Two CI gates in frontend/ currently pass without validating anything. This makes
both real.

npm run typecheck checks zero files. It is defined as tsc --noEmit, but
frontend/tsconfig.json is solution-style ("files": [] plus references), and
tsc --noEmit without -b does nothing on such a config. Verified with
npx tsc --noEmit --listFiles, which emits 0 files. So make frontend-typecheck
and the typecheck step of frontend-ci have been vacuous. Type errors were only ever
caught incidentally by npm run build, which does run tsc -b. Changing the script
to tsc -b makes it check 1,444 files.

The coverage gate measures about a fifth of the codebase. v8 only instruments
files that a test imports, and vitest.config.ts sets no coverage.include, so the
denominator is "whatever the tests happened to pull in". Measured before this change:
45.9% lines (1,404/3,057) against a real tree of 17,839 lines — an honest 7.9%.

Worse, the gate is non-monotonic: adding the first test to a large untested file
lowers the reported percentage by widening the denominator. Adding one test that
imports ConfigTab (~2,400 lines) would have dropped coverage to roughly 31% and
turned CI red. The gate actively penalised writing the first test for any big module.

Setting a fixed whole-src denominator makes coverage monotonic — adding a test can
now only ever raise it — and comparable over time. The headline number drops to
single digits because that is the truth about a ~95k-line frontend.

Changes

• frontend/package.json: typecheck script tsc --noEmit → tsc -b.
• frontend/vitest.config.ts: add coverage.include: ['src/**/*.{ts,tsx}'], an
  exclude list (test files, src/main.tsx, *.d.ts), and coverage.thresholds
  re-baselined just under the honest measurement.
• Thresholds are now single-sourced in vitest.config.ts. Removed the duplicated
  --coverage.thresholds.lines=40 flag from the frontend-test Makefile target and
  from package.json's ci script.
• Makefile: replace the stale "set just below current measured (~44%)" comment with
  one explaining the whole-src denominator and the monotonicity property.
• CLAUDE.md: the documented figure said 35%, the Makefile enforced 40%, and neither
  described what was being measured. Corrected.

Test Plan

• Shared checks pass (make ci)
• Release check passes if packaging or deployment changed (make release-check) — n/a, no packaging change
• Manually tested the affected feature(s) — see verification below
• Updated CHANGELOG.md for user-facing or operator-facing changes — not done; this is operator-facing (CI behaviour), please advise on preferred wording
• Updated deploy/release docs — CLAUDE.md corrected; no install/release path change

Verification performed:

• npx tsc --noEmit --listFiles | wc -l → 0 before, npx tsc -b --listFiles | wc -l → 1444 after.
• Proved the gate now bites: injected const x: number = 'not a number' into a src
  file and confirmed npm run typecheck fails with
  TS2322: Type 'string' is not assignable to type 'number'; reverted and confirmed
  it passes again. Exit 0 alone was not accepted as evidence, since that is precisely
  the signal that hid the problem.
• make frontend-ci exits 0.
• grep -rn "thresholds.lines" Makefile frontend/package.json returns nothing.

Note for reviewers: tsc -b surfaced no pre-existing type-error backlog, because
npm run build had been running it all along. The broken script was buying false
confidence, not hiding real damage.

Related Issues

Closes #