Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:1pqmwfsand is past its budget: trevato/forge: "the gate audit before any shard > a new file is in the gate with no list naming it, and explicit files … #5698

The sentinel's test, "a new file is in the gate with no list naming it, and explicit files are not audited" in test/shards.test.ts, now stops the runner as soon as it has what it asserts. I couldn't reproduce the red here, so the cause is inferred from the code. bun test test/shards.test.ts passes (69 tests) and tsc --noEmit is clean.

Why I think it failed. The test never needed to run anything. It needs the gate audit to pass and the matrix slice banner to print, and both come before any bun test is spawned. But it let the runner carry on into a real bun test run of the file it had just sliced, twice. On a loaded check machine, that spawn is what made the test slow and flaky.

What changed.

• Kill at the banner: the run helper in the audit describe takes an optional stopAt marker and kills the runner once stderr carries it.
• Both runs use it: the --gate --shard N/N run and the explicit-file run (now --shard 1/1, so it prints a banner too) stop at matrix slice.
• New assertion: the explicit run also checks the banner reads 1 of 1 files.

What I left out. No log from the failing runs was available, so I could not confirm the load theory against the actual failure. Other tests in the file that spawn the real runner (for example the --tier fast one) are unchanged. The sentinel cause should clear after the next green check on main.

Closes #5607

The sentinel's test, "a new file is in the gate with no list naming it, and explicit files are not audited" in test/shards.test.ts, now stops the runner as soon as it has what it asserts. I couldn't reproduce the red here, so the cause is inferred from the code. bun test test/shards.test.ts passes (69 tests) and tsc --noEmit is clean.

Why I think it failed. The test never needed to run anything. It needs the gate audit to pass and the matrix slice banner to print, and both come before any bun test is spawned. But it let the runner carry on into a real bun test run of the file it had just sliced, twice. On a loaded check machine, that spawn is what made the test slow and flaky.

What changed.

• Kill at the banner: the run helper in the audit describe takes an optional stopAt marker and kills the runner once stderr carries it.
• Both runs use it: the --gate --shard N/N run and the explicit-file run (now --shard 1/1, so it prints a banner too) stop at matrix slice.
• New assertion: the explicit run also checks the banner reads 1 of 1 files.

What I left out. No log from the failing runs was available, so I could not confirm the load theory against the actual failure. Other tests in the file that spawn the real runner (for example the --tier fast one) are unchanged. The sentinel cause should clear after the next green check on main.

I merged main into the branch and pushed it. The only conflict was in test/shards.test.ts, in the gate audit's new-file test. I ran only test/shards.test.ts (69 pass, 0 fail) and the type check (clean), not the whole suite. The forge will run its full check on the push.

• What main changed: it runs the whole gate as one slice (--shard 1/1), so the banner now reads matrix slice 1/1 (N of N files).
• What this pull changed: the test stops the runner at the matrix slice banner, so its verdict doesn't wait on a bun test spawn.
• Resolution: the test keeps both. It uses main's 1/1 slice and count, and passes this pull's stop-at-banner arguments to both run calls.