gc-stress: test_gap_gc_net_once_flags_rekey (added by #8216, never executed in CI) SIGSEGVs deterministically under force_verify — reds pr-gate on every rebased PR #8259

test_gap_gc_net_once_flags_rekey — the witness #8216 added (18:15, with its rooting fixes and the gc_repsel_corpus.txt registration) — SIGSEGVs deterministically under the force_verify arm of the GC × repsel matrix:

FAIL test_gap_gc_net_once_flags_rekey (exit=139 cycles=3 evacuated=0 scavenged=9895 reclaimed=13225440)
matrix row: gc_net_once_flags_rekey   UNVER UNVER PASS UNVER FAIL UNVER PASS   (FAIL = force_verify)

Two runs, byte-identical counters (cycles=3 scavenged=9895 reclaimed=13225440) — perfectly reproducible, which per the rooting-bug playbook points at an unregistered/unpruned table holding a raw heap pointer, not a racy unrooted register.

This witness has never completed a CI run. #8216's only Tests run had gc-stress cancelled (run 31957836547 — merged during yesterday's queue saturation), so the test landed with zero executions. It first ran on PR #8244 (whose diff is workflow/scripts-only and cannot affect GC), failing identically on attempt 1 and 2: runs 31964669242 attempts 1+2.

Suspects: the #8216 fix itself being incomplete under forced evacuation (force_verify = PERRY_GC_FORCE_EVACUATE + PERRY_GC_VERIFY_EVACUATION), or interaction with the same-day #8174-family rekeyed-table pruning. evac_minor PASSES, so it is specifically the verify/forced combination.

Until fixed, this cell fails gc-stress in every tier — i.e. pr-gate on every rebased PR. If the fix isn't quick, consider an XFAIL triage for the cell (with this issue number) rather than softening the job.