perry-ext-net: gc_mutable_scanner_rewrites_listener_roots fails on main

[proggeramlug]

perry-ext-net's gc_mutable_scanner_rewrites_listener_roots fails on clean main (reproduced at ad25921e7).

test tests::gc_mutable_scanner_rewrites_listener_roots ... FAILED
panicked at crates/perry-ext-net/src/tests.rs:59:5
test result: FAILED. 27 passed; 1 failed

Line 59 is:

fn assert_rewritten(before: i64, after: i64) {
    assert_ne!(after, before);
    assert!(perry_runtime::arena::pointer_in_nursery(after as usize));
}

So the test requires a GC root to have moved across a collection, and it is the assert_ne! that fires — the object did not move. That is the "fixture allocated but nothing was evacuated" shape: the test cannot distinguish "the mutable scanner failed to rewrite the root" from "no evacuating collection ran at all", and right now it is failing for one of those two reasons.

Two possibilities worth separating:

1. the scanner genuinely stopped rewriting listener roots — a real GC bug;
2. the fixture no longer drives an evacuating minor in this environment, so after == before because nothing moved.

The second is the more likely reading given the test is asserting movement rather than correctness of a value, and it is the same class as other fixtures here that allocate without churning. Either way the test should assert its subject ran (e.g. that a copying minor actually occurred / copied_objects > 0) before asserting the address changed — otherwise a green run does not mean the scanner works, and a red one does not mean it is broken.

Reproduce:

RUST_TEST_THREADS=1 cargo test --profile perry-dev -p perry-ext-net --lib

Found while auditing #8632; confirmed not caused by it (identical failure on clean main).

[proggeramlug]

Sharper diagnosis — it is not random flakiness, it deterministically depends on the collector mode:

default                      test result: FAILED. 27 passed; 1 failed
PERRY_GC_FORCE_EVACUATE=1    test result: ok.     28 passed; 0 failed

Reproduced on perry-ext-net @ e727da9e4 + #8637, single-threaded, back to back.

That matches the assertion exactly: assert_rewritten requires assert_ne!(after, before) — the root must have moved. With no evacuating collection the object stays put, after == before, and it fails. So the test's precondition is "an evacuating minor ran", and it currently just assumes that rather than arranging or asserting it.

Corroboration from outside: #8637's own validation line reads "perry-ext-net: 28 passed with forced evacuation" — the author ran it the way it needs to be run, which is why they saw green where a default cargo test sees red.

Two ways to fix, either is fine:

1. have the test set PERRY_GC_FORCE_EVACUATE (or otherwise drive an evacuating minor) itself, so it is self-contained; or
2. assert the subject ran first — check a copying-minor counter (copied_objects > 0) before asserting the address changed, so a run that never evacuated skips rather than failing.

(2) is the more honest shape: as written, a green run does not prove the mutable scanner rewrites roots — it only proves an evacuation happened to occur. That is the same "assert the subject ran" gap as the #8625 fixture.