test(runtime): perry-runtime's full suite is flaky on main — different tests fail across runs, reproduced on a pristine worktree #7946

Summary

cargo test -p perry-runtime (full suite) is flaky on main, and CI runs cargo test --workspace, so it is a live source of red builds that get attributed to whichever PR happens to be in flight.

Evidence

Found while validating #7900/#7901/#7902 (gc-handoff/GCSAFE-NOTES.md):

• Two runs on a feature branch each failed one test — a different test each time.
• A pristine b8c1f103e worktree then reproduced run 1's failure with a byte-identical message, confirming it is not branch-attributable.

Why this matters more than an ordinary flake

The failure lands on whoever is merging. Several GC PRs merged today with admin bypass; a flaky required suite makes it impossible to distinguish "my change broke this" from "this was already broken", which is exactly the condition under which a real regression gets waved through as "the usual flake".

CLAUDE.md's own framing applies: a gate that fails for reasons unrelated to the change is not a gate, it is noise that trains people to bypass it.

Suggested first step

Identify the flaky set and whether they share a cause (test-order dependence, a process-global GC counter, or shared thread-local state across cargo test's thread pool are the obvious candidates given the subject matter). Then either fix, serialise, or quarantine them explicitly — quarantine being far better than leaving them to fire at random.

Note perry-runtime tests share process-global collector state, and several GC tests use RAII thread-local overrides (OldDefragTestEnable, OLD_DEFRAG_TEST_OVERRIDE, barrier-arming overrides). Test-order or parallelism interaction there would produce exactly this signature.