test(runtime): telemetry_verifier asserts a wall-clock pause budget and fails ~2 runs in 100 on a loaded host #7956

Summary

gc::tests::telemetry_verifier::allocation_heavy_arena_debt_reports_budgeted_steps_and_debt asserts a wall-clock soft target and fails on a loaded host:

ordinary pause steps should stay in budget:
"pause_steps[22] elapsed 4936us exceeded soft target 2000us"

(crates/perry-runtime/src/gc/tests/telemetry_verifier.rs:109)

Rate measured on an M1 mini running at load ~60: 2 runs in 100 on main (origin/main @ 1bd5eeb6b), and 1 run in 300 after #7954 landed the shared-state fixes. It is orthogonal to #7946 — nothing is shared between tests here; the step genuinely took 4.9 ms because the box was oversubscribed.

Why it matters

cargo test --release --workspace is a required check. A wall-clock assertion in it fails for reasons unrelated to the change under review, which is the condition #7946 was opened about: it trains people to re-run rather than to read the failure.

Not fixed by widening the bound

The 2 ms soft target is presumably a real pacing claim, so raising it is a change to what the test asserts, not a flake fix — and a bound wide enough for a load-60 host asserts nothing on an idle one. Options worth weighing:

• assert on work units / step count (a deterministic quantity the pacer actually controls) rather than elapsed microseconds, and keep the microsecond figure as a reported diagnostic;
• keep the timing arm but gate it behind an env opt-in run only on the quiet bench host (perry@perry-macos.local), the way the benchmark ratchets already are;
• if the timing claim is genuinely the subject, move the case out of the per-PR cargo-test gate into the nightly/bench job that owns a quiet machine.

Whichever way: the acceptance criterion is that the case either cannot fail for host-load reasons, or does not run in a gate that blocks merges.