test/bench-ablation.test.ts flakes under load and has now failed CI twice

[MongLong0214]

runner: ablation conditions > accepts all six arms has failed CI on two separate PRs (#79, #87) and fails locally under concurrent load. It passes in isolation every time.

Why this is worth fixing rather than re-running

A flaky test in a required check trains everyone — including me, twice today — to re-run without reading the failure. That is the same habit that let CI stay red for eight commits earlier in this project while being reported green five times.

It also costs a full CI cycle each time, and it lands on whichever PR happens to be in flight rather than on the change that would have caused a real failure.

What is known

• Passes alone: npx vitest run test/bench-ablation.test.ts → 20/20
• Fails under load: locally with several concurrent processes, and on GitHub's runners
• The failing assertion is in the six-arm condition test; the error surfaces as Command failed: from a spawned node process, which suggests a timeout or a resource limit rather than a logic error

Direction

Establish which it is before changing anything — a timeout raised to hide a real contention bug is worse than the flake. If it is a timeout, the test spawns real processes and its budget should scale with available parallelism rather than being a fixed 5000 ms. test/mcp.test.ts has the same 5000 ms timeout symptom under load and may share a cause; check both together.

[MongLong0214]

Fixed in PR #91. Diagnosed as a real contention bug, not a timeout: four test files each rebuild the shared dist/ in their own beforeAll, racing bench-ablation's digest-consistency check. Reproduced deliberately (4/20 and 1/15 runs under concurrent tsc), and proved a timeout could not be the cause — execFileSync blocks the event loop, so vitest's timer never engages. Fix gives the benchmark a private dist/ via COMMITLORE_BENCH_DIST_DIR; 20/20 clean under the same load, 3/3 consecutive clean full-suite runs.