The runner stacked two independent parallelism knobs: OMP_TEST_CONCURRENCY
spawned N `bun test` processes while each process ran its own --parallel=M
test files, so the workspace bucket put 4 x 8 = 32 files in flight on a
4-core runner. bun's per-test timeout is wall-clock, so CPU-starved suites
crossed the 5s default and failed at random - mnemopi's sqlite/CLI files
tripped a different pair every run.
- TestCommand now carries a `parallel` request instead of baking the flag
into argv; the dispatcher resolves it against one shared budget
(availableParallelism x 2, split by the live pool width) so total
in-flight files track the machine. A chunk that runs alone still gets
its full requested width, leaving the sequential CI path unchanged.
- Raised the per-test timeout to 30s (OMP_TEST_TIMEOUT to override).
Suites here build real SQLite schemas and spawn CLIs, already running
1-4s per case on a quiet runner; the 10-minute chunk watchdog stays the
backstop for an actual hang.
- --dry-run now resolves the same budget, so it prints the argv a real run
would use, and the pool header reports cores plus the granted width.
- Dropped the dead `{ smol: true }` argument: workspaceTestCommand never
accepted it, and this file's own findings say a smaller heap makes bun
1.3.14's GC crash more often, so it should not be wired up.
can1357
08819b279c