test: namespace_members_exist_with_expected_shapes fails deterministically under default-parallel cargo test (green serially)

[proggeramlug]

Summary

global_this_webassembly::tests::namespace_members_exist_with_expected_shapes
(crates/perry-runtime/src/object/global_this_webassembly.rs:1067) fails deterministically when
cargo test -p perry-runtime --lib runs with default parallelism, and passes reliably under
--test-threads=1.

Failure is the assertion at global_this_webassembly.rs:1110:

Module.prototype must exist

Why it is worth a ticket rather than a shrug

"Flaky in parallel" is usually thread-scheduling noise. This one is deterministic in parallel, which
points at real cross-test state — most likely a shared global/thread_local registry that another
test in the same binary tears down or re-initialises while this one reads it. That is a genuine
ordering hazard in the WebAssembly namespace install, not a test-harness artifact.

Not a CI blocker, and that is exactly the risk

CI runs RUST_TEST_THREADS=1, so the required cargo-test check does not see this. It is only
visible to developers running cargo test locally the ordinary way — where it reads as noise and
trains people to ignore local reds.

Context

Surfaced while A/B-ing #6957 on a quiet 8-core arm64 box. Pre-existing and unrelated to that fix:
at 0bb03e82f (pre-#6893) default-parallel --lib already fails 2–4 per run across
global_this_webassembly, native_module_stream, prop_plan, gc::tests::teardown,
closure::dynamic_props, and gc::tests::runtime_roots. PR #6963 removed 33 serial failures and
added none, but did not touch this family.

This issue covers namespace_members_exist_with_expected_shapes specifically because it is the one
member of that set that is deterministic rather than intermittent, which makes it the cheapest to
root-cause and the most likely to explain its neighbours.

Acceptance

• Identify the cross-test state involved and make the test order-independent (or make the namespace
  install idempotent/re-entrant if the hazard is real outside tests).
• Confirm by running --lib in parallel repeatedly with no failure of this test.
• Report whether the same root cause explains any of the other five families listed above.