Check time under 2 minutes for a typical pull: Bun-native affected tests, real timings, split the two slowest files, fast git and SQLite in tests #2038

Probe 2026-10-16: check median 697 s, p90 1307 s; scripts/test-times.json times 52 of 385 test files (the rest weigh by bytes); test/studio.test.ts 196.9 s and test/apps-adversarial.test.ts 145.9 s set the floor of any full run (one file per process); SHARDS_MAX = 8 while the cell has 16 CPUs. Bun 1.3.13 (our version) has bun test --changed=<ref> (only tests that import a changed file), --parallel[=N], --isolate, --shard=i/n (verified with bun test --help; --timings is NOT in 1.3.13).

Done, measured before/after on this repo in the pull:

1. Fast checks: compare bun test --changed=$FORGE_CHECK_BASE with our impact map on the last 50 pulls; use whichever picks the smaller set that never missed a red the full gate found (non-import triggers - fixtures, forge.json, scripts/, bun.lock - stay run-all).
2. bun scripts/test-shards.ts --record on the vxrail; commit the full table (every file timed).
3. Split test/studio.test.ts and test/apps-adversarial.test.ts so no file runs over 45 s.
4. Test git env: core.fsync none, GIT_CONFIG_NOSYSTEM=1, GIT_CONFIG_GLOBAL=/dev/null, GIT_OPTIONAL_LOCKS=0, fixed author dates; a per-worker template repo copied with git clone --local instead of init+commit per test.
5. Test SQLite: migrate once per worker, Database.deserialize(db.serialize()) per test; synchronous=OFF, journal_mode=MEMORY except the durability tests.
6. SHARDS_MAX follows the cell's CPUs (measure 8 vs 12 vs 16).