release blocker: test_parity_perf_hooks regressed on linux (parity shard 4)

[proggeramlug]

Symptom

parity (4) fails on linux in full-tier run 33372993990 (candidate 83754818ea):

NEW FAILURES on linux (not allowed for this platform):
  - test_parity_perf_hooks

parity (4) was green on the previous candidate 01463b8161 (run 33346563641), so this regressed inside that window.

Platform

Reported as a linux-only new failure. Worth confirming whether it reproduces on macOS before assuming it is platform-specific — the parity harness classifies per-platform, and a macOS-passing/linux-failing split is itself a useful clue.

Reproduction

# Let the harness build: its BUILD_PACKAGES must come from one cargo build or
# feature unification differs and you get bogus failures.
./run_parity_tests.sh --filter test_parity_perf_hooks

If using a prebuilt compiler instead, set PERRY_SKIP_BUILD=1, PERRY_BIN, and PERRY_RUNTIME_DIR to a matching pair — and rebuild -p perry -p perry-runtime-static -p perry-stdlib-static after any git checkout, or the compiler/runtime coherence check refuses every fixture (Error: runtime library does not match this Perry compiler, surfacing as perry compile failed).

Attribution: unknown

Not investigated. The window 01463b8161..83754818ea is large. Note that perf_hooks has prototype-wiring in perf_hooks/prototypes.rs that uses object_set_static_prototype — one of ~20 runtime sites that set OBJECT_META_FLAG_PROTO_OVERRIDE (see #9251) — so #9169's prototype-override work is worth ruling in or out early. Rule it out by measurement, not by commit-window correlation: that reasoning produced three wrong attributions in one session, including one on a PR that had to be publicly retracted.

Acceptance criteria

• test_parity_perf_hooks matches node on linux.
• Cause identified rather than the expectation adjusted.