gc-matrix: four of the six PR-gating arms run ZERO copying minors corpus-wide (default/verify_evac/cons_scan_off at copy-minor 0/49; header still claims 12/22) #7255

scripts/gc_repsel_matrix.sh's PR_ARMS subset is what gc-stress runs on a pull request. Four of its six arms run zero copying minors across the entire corpus, so on a PR they can only ever produce UNVER.

Measured at origin/main = 64c1f56fb, --arms all --pressure 8, node 26.5.1, 49 corpus files — the run's own liveness summary:

default                  requires=scavenge  collected 24/49   moved-objects 0/49   copy-minor  0/49
verify_evac              requires=scavenge  collected 24/49   moved-objects 0/49   copy-minor  0/49
cons_scan_off            requires=scavenge  collected 24/49   moved-objects 0/49   copy-minor  0/49
cons_scan_off_force      requires=scavenge  collected 24/49   moved-objects 0/49   copy-minor  0/49
shipped_default          requires=none      collected  3/49   moved-objects 0/49   copy-minor  0/49
evac_minor               requires=move      collected 48/49   moved-objects 48/49  copy-minor 48/49
force_verify             requires=move      collected 48/49   moved-objects 48/49  copy-minor 48/49

PR_ARMS = default,evac_minor,verify_evac,force_verify,cons_scan_off,shipped_default.

Why this matters more than a stale comment

The script's header documents default as the arm that closed the per-PR hole, in the strongest terms it has:

THIS SUBSET CAN NOW REPRODUCE THE RELOCATING-MINOR DEFECT CLASS (#6993). Until #7024 it could not, and that was the hole … So the whole "raw reference held across a relocating collection" class — #6951, #6972, #6982, #6991, #6992 — was invisible per PR and could only go red after merge, on push.

and quotes the measurement that justified it:

arm            copy-minor before #7024   after
default              0/22                12/22

Today it is 0/49. The hole the header declares closed is open again, and the header is the reason nobody re-derived it: it reads as a settled fact with numbers attached.

Two further observations from the same measurement:

• The --pressure knob does not move this. evac_minor on test_gap_repsel_p4a3_ptr_numarray reports cycles=1 scavenged=3585 identically at --pressure 8, 4, 2 and 1. Turning the pressure up does not turn the requires=scavenge arms on.
• An all-UNVER table exits 0. gc_repsel_matrix.sh's exit status counts only FAIL. gc-moving-witnesses wraps its invocation in a checker that rejects UNVER as hard as FAIL — deliberately, and its workflow says why. gc-stress has no such step, so "the four arms went inert" is not a signal it can emit.

Probable cause, not verified

#7161 flipped the evacuating minor default-OFF pending #7154, which is also why the pinned gc-ratchet baseline currently reports minor_cycles=0 everywhere (noted in #7194). The requires=move arms carry %E% (PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off) and still relocate; the requires=scavenge arms deliberately do not, which is the whole point of them — they are supposed to prove the shipped route relocates. Whether the 0/49 is entirely #7161 or also involves the --pressure/defer-cap interaction of #7024/#7025 is not established here.

What should not happen

Making gc-stress reject UNVER today would turn the job permanently red on four arms with no triage — the untriaged-permanent-red state #7194 was opened about. The order is: decide what the arms should be under the current default (revert #7161, re-tune, or re-declare the arms' requires= honestly), then add the assertion.

Related: #7194 (the red cell that prompted the measurement, now fixed), #7187 (lazy barrier arming / the #7161 revert timeline), #7024, #7025, #6993.