A red main fails every pull's check: tell a pull's own red from main's, and keep main from landing red #10304

On 11-09 17:08-18:54Z, 5 of 19 failed checks were red on main, not on the pull: header width (#10252) three times, then unreached src/spawn/pod.ts (a6750c73) and the src-only boot broken by an import-time read (d7f940b8) twice. Each landed green because the fast tier picks tests by an import map, and a test that scans the tree is tied to no import. Each pull after it ran the full suite on its merge and went red, and the crew reworked pulls that were fine.

3212895a adds the five known tree scans to RULE_TESTS (src/checks/tiers.ts). That is a hand list, and the next scan someone writes will be missing from it.

Outcome. A pull is never red for a test that is red on main at its base: the check runs the failing test on main's tree and, when it fails there too, says so and does not count it against the pull. A tree scan is found by what it reads (the impact map records the files a test opens, not only the modules it imports) or by declaring itself, so the fast tier never misses one.

Test. A pull that adds an unimported module is red on its own fast check. A pull opened while main is red on a test it does not touch is green, and its check says the test is red on main.

Try: on a forge whose main fails test/unreached.test.ts, open a pull that changes only README.md and read its check: green, with main's red named