GC test flake: gc::tests::barrier::test_dirty_page_map_entry_scan_is_external_range_bounded SIGSEGVs intermittently in the full perry-runtime suite #11362

gc::tests::barrier::test_dirty_page_map_entry_scan_is_external_range_bounded intermittently crashes the perry-runtime lib suite with SIGSEGV.

Observed (2026-09-26, macOS aarch64, RUST_TEST_THREADS=1 cargo test --release -p perry-runtime --lib):

• While validating GC: restore_surviving_dirty_coverage 'page(s) not remembered' assertion fails intermittently (json_construction_growth_mixed_layouts test) #11353/fix(gc): remember a rejected raw word the way the coverage walk decodes it (#11353) #11361: it crashed in both arms (pristine main and the fix branch) of a loaded mass run of 301 full-suite runs each, so it doesn't depend on that change.
• While validating the perf(ic): answer dynamic arr.length from the Array's GC header at the call site #11358 rebase on main c92da9d: it crashed the first full-suite run with SIGSEGV. The rerun passed 4607/0.
• In isolation it doesn't reproduce: perry_runtime-<hash> gc::tests::barrier passed 60/60 on main dc70c80.

So it depends on state left behind by earlier tests, or on process address layout. The test name suggests the external-range bound in the dirty-page-map entry scan. A crash means something dereferences an address outside that bound, either the scan or the test fixture's synthetic entries. That is either a real out-of-range read in the collector or a fixture that trusts a stale global. The same class of bug as #11353: a layout-dependent disagreement surfaced by residue from an earlier test.

Also seen once in the #11353 mass runs, and possibly related: SIGSEGV in gc::tests::runtime_roots::hook_dispatch_handles::test_async_resource_event_emitter_link_follows_a_moved_subclass_emitter, 7 of 301 runs on a pre-#11338 main. After #11338 it passes 60/60 in isolation, but a full-suite recheck is still pending.