compiler-output-regression: the native-ABI proof step was dark for 3 weeks behind an earlier failing step #8855

While attributing #8489 it emerged that the compiler-output-regression job's "Gate native-ABI proof compiler output" step did not execute at all between 2026-07-30 and 2026-08-17.

The earlier "Gate native-region proof compiler output" step was failing, and a failing run: step aborts the remaining steps in the job. The native-ABI step only began reporting once region-proof went green on Aug 18 — which is why the control_flow change looked like it appeared from nowhere on Aug 20, two days later, when its actual cause (40e2ce86d, #8457) landed inside that window and would have been caught immediately had the step been running.

This is CLAUDE.md's fourth failure mode verbatim — "the gate runs but its subject never did" — and the most dangerous one, because the job is genuinely present in the run list and its failure is attributed to whichever step happens to fail first. A three-week blind spot in a compiler-output change detector is exactly what that section warns about.

Why it matters beyond this one instance

The steps are independent subjects: region-proof failing tells you nothing about native-ABI proof. Chaining them in one job means any long-lived failure in an earlier step silently suspends every later one, and the suspension is invisible — the job is red either way, so nobody looks for the second finding hiding behind the first.

Options

1. Split the steps into separate jobs, so each reports independently. Costs runner slots (the header of test.yml notes the 20-slot org constraint, which is why these were consolidated).
2. Keep one job but let the steps run to completion — collect failures and fail at the end, rather than aborting on the first. Cheapest in slots and preserves the current structure.
3. Assert liveness: have each gate emit a "subject ran" marker and fail the job if a marker is missing, so a skipped subject is distinguishable from a passing one.

I have not changed the workflow — reordering steps or adding continue-on-error changes CI semantics and deserves a deliberate decision rather than a drive-by edit.

Found while working #8489 (attributed in #8854).