GC: restore_surviving_dirty_coverage 'page(s) not remembered' assertion fails intermittently (json_construction_growth_mixed_layouts test) #11353

gc::tests::runtime_roots::json_construction::json_construction_growth_mixed_layouts_and_errors_leave_a_walkable_heap fails intermittently in the perry-runtime release lib suite.

The failure is the debug/test assertion in restore_surviving_dirty_coverage (crates/perry-runtime/src/gc/verify.rs, ~line 464):

restore_surviving_dirty_coverage: 1 page(s) of N dirty-scan-covered object(s) are not remembered — the dirty scan's per-slot re-remembering disagrees with the coverage walk for an object `scan_dirty_object_slots` reported complete

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

• Pristine main (3f6eb6c): failed in 1 of 3 full-suite runs.
• A PR branch that doesn't touch the GC (fix(runtime): install get [Symbol.species] on built-in constructors (#11193) #11338): failed in 2 of 6 runs, the same test with the same message.
• Passes when run alone, so it depends on state left behind by earlier tests in the single-threaded order: arena/remembered-set residue or the malloc layout. It could be a real disagreement between the dirty scan's per-slot re-remembering and the coverage walk, surfaced only under a particular heap layout. It could also be global state from an earlier test, the CI: perry-runtime --lib cargo-test is flaky (event_pump timing panics + intermittent SIGSEGV) #1444/Process-global side tables are cleared by test guards that readers are not required to take — three flakes in two days #7672 isolation class, where a fixture precondition fails.

It needs triage to tell which. If it is the former, it is a remembered-set correctness bug, because a page the dirty scan skipped would not be re-scanned on the next minor.