flaky: perry-codegen --lib fails ~2/12 on main (opt_report + ext_registry global state races a required check)

[proggeramlug]

Summary

cargo test -p perry-codegen --lib fails intermittently on main at roughly 2 runs in 12,
always in one of two families:

• collectors::ptr_shape::opt_report_tests::* — e.g.
  a_region_lowered_twice_still_collapses_and_says_how_much
  (left: 3, right: 2 on opt_report::masked_by_dedup()) and
  only_the_return_position_is_marked_served
• ext_registry::tests::ext_prefix_net_does_not_over_match

It is a test-isolation race, not a logic bug: the same suite passes 3/3 with
-- --test-threads=1, and the assertions read process-global state —
static MASKED_BY_DEDUP: AtomicUsize in crates/perry-codegen/src/opt_report/mod.rs:1136,
drained/reset by opt_report::testing::Session::start(). Session does take a serialising
Mutex, so some concurrent test is recording into the global entry buffer (or reading
masked_by_dedup()) without holding a Session.

Why this matters

cargo-test is a required branch-protection context. A ~17% per-run failure rate means
roughly one in six PRs goes red for a reason that has nothing to do with the change under
review, and — worse — trains reviewers to re-run red cargo-test results, which is exactly
how a real regression gets waved through.

Reproduction

git checkout main
for i in $(seq 1 12); do
  cargo test -p perry-codegen --lib 2>&1 | grep "test result"
done
# 2/12 FAILED here (Apple M1 Max, macOS 26.5, perry 0.5.1279 @ cdc7dee87)

cargo test -p perry-codegen --lib -- --test-threads=1   # 3/3 green

Likely fix

Audit every test that can emit an opt-report entry or read masked_by_dedup() /
take_entries() and make it acquire Session (or Session::start_disabled()), so the
serialising lock actually covers all users of the global. ext_prefix_net_does_not_over_match
looks like the same shape against the extension registry's global state and should be checked
at the same time.

Found while verifying #7296 (array-index range proofs); confirmed pre-existing on a detached
origin/main worktree, so it is not caused by that PR.