ci(static): run the unit suite once, under coverage

[jouwdan]

Closes MEI-127.

The static job ran pnpm test and then pnpm test:coverage — the same ~7,746 tests across 444 files, twice, back to back. --coverage changes what is measured, never what is collected, so the first run established nothing the second did not.

Measured

Per-step timings from list_workflow_jobs on two green runs:

	run 680	run 681
Setup, install, all 21 correctness gates, Redis	1m 18s	1m 25s
pnpm test	4m 56s	4m 46s
pnpm test:coverage	5m 33s	5m 20s
Static checks total	11m 52s	11m 37s

The coverage step is ~35s dearer than the plain one — report generation and threshold checking, not slower tests.

Projected after: ~6m 55s. The job is strictly sequential, so that is job-minus-step arithmetic on measured values — but it is a projection, not an observation. This PR's own run is the first real figure.

Static checks is the last job to finish in both runs, so the whole-run wall clock moves with it.

Why this is safe

• --coverage selects a provider; it does not touch test.include, so the collected set is identical. The V8 provider reads the inspector's coverage rather than rewriting sources, so there is no transformed code under test. A 224-test subset weighted toward timing-sensitive files ran 3.15s plain vs 3.05s instrumented — nothing for a marginal timing assertion to trip over.
• Nothing depends on the removed step by name. Check runs are named per job, not per step, so branch protection cannot reference it; the Static checks context is unchanged. Neither release workflow invokes either script.
• pnpm test remains a script. pnpm verify chains it, and the migrations job still runs it with TEST_DATABASE_URL set for the seams that need a real Postgres.

No threshold changed, no gate removed.

What was considered and rejected

Splitting the gates into their own job. Its stated benefit does not exist: the gates already run before the tests and a job aborts at its first failure, so a broken lint rule or doc anchor already fails at ~1m 20s. Eleven minutes was only ever the cost of a green run. A split would run the gates in parallel with the tests — ~50s off this job, and zero off the run, because the browser shards are 5m 55s.

Sharding the unit suite. It would work, and buy nothing, for the same reason. Against that sits a real cost: each shard sees coverage only for the files its own tests touched, so thresholds must be disabled per shard, partial reports merged, and thresholds re-judged on the merge — a step that would pass silently if it produced an empty report. That is a hollow gate taken on for no wall-clock gain.

vitest.config.ts's maxWorkers: 4 matches the 4-vCPU ubuntu-latest runner and is left alone.

Not fixed here

Six gates chained in pnpm verify run in no CI workflow: workspace:check, i18n:check, board:gen:check, marketplace:gen:check, board-installer:gen:check, vercel-template:gen:check. A pull request breaking any of them merges green. Tracked as MEI-128 rather than widened into this change.

pnpm verify passes: 7746 tests.

---

Generated by Claude Code