A check never takes the forge down: each check cell has a real memory cap, and test processes stay small #2410

Probe 2026-10-16 12:37:40Z: the forge container was OOMKilled (exit 137) at its 96 GiB pod limit; pod cgroup memory.peak 99,514,306,560 bytes. After the restart: 29 bun test processes, each running ~110 test files in one process (fast-tier slices, scripts/test-shards.ts:466 spawns bun test ...paths), 230-380 MiB each and growing file by file (one global per process); 9 checks ran at once; forge.json declares each check cell 8192 MiB but nothing enforces it at the cgroup (the watchdog in fd27b1b2 reads the declared figure; the kernel never caps the cell), so the checks together plus the crew reached the pod limit. checks.concurrency lowered 9 -> 6 by the steward as the stopgap.

Done: (1) each check cell runs under its own memory.max (cgroup v2, from forge.json check.limits.memory) so one check is killed alone, never the forge; (2) a test process runs at most N files (measure: peak RSS vs files per process on the vxrail; pick N so RSS stays under ~1 GiB) or uses --isolate only after measuring Bun 1.3.13's per-file growth (oven-sh/bun#31771 reports ~4 MB/file under --isolate); (3) /system shows each check cell's memory beside its cap; (4) a test runs a check whose tests allocate past the cap and asserts the check fails alone while the forge stays up. Then checks.concurrency can go back to 9.