probe_dispatch_tests: the_magic_screen vacuity guard fails intermittently on heap layout

[proggeramlug]

the_magic_screen_covers_every_symbol_and_no_ordinary_object fails intermittently, depending on heap layout rather than on the code under test.

Observed on perry-runtime @ e5a2a6f5e + PR #8638, single-threaded, identical command each time:

run 1: FAILED. 2637 passed; 1 failed
run 2: ok.     2638 passed; 0 failed
run 3: ok.     2638 passed; 0 failed

The failing assertion (probe_dispatch_tests.rs:258) is a vacuity guard, not a correctness check:

let excluded_without_the_screen = match obj_type {
    GC_TYPE_SET    => crate::set::is_registered_set(sym),
    GC_TYPE_MAP    => crate::map::is_registered_map(sym),
    GC_TYPE_REGEXP => true,
    _ => false,
};
assert!(!excluded_without_the_screen,
    "... the screen is then not load-bearing and this suite is vacuous");

It allocates eight leaked symbols and reads the bytes immediately before each as a GcHeader. Those bytes are whatever the allocator last left there, so obj_type is a function of allocation history. When the preceding bytes happen to read as GC_TYPE_SET/GC_TYPE_MAP and that address is a registered set/map — or as GC_TYPE_REGEXP, which is unconditionally true — the guard trips and the suite goes red without anything being wrong.

Note it also passes in isolation: filtering to just this test (-- the_magic_screen_covers_every_symbol) passes on both main and #8638, because the filter changes the allocation history. So a filtered re-run is not a valid reproduction attempt — it has to be the full suite.

Why this matters beyond the noise: a guard that is supposed to prove the suite is non-vacuous currently fails for reasons unrelated to whether the screen is load-bearing. In its current form it cannot distinguish "the magic screen stopped mattering" from "the allocator happened to leave SET-shaped bytes here", so a red does not mean what it says — and it costs real time, since the honest response to it is a full attribution run against main.

Suggested direction: make the eight probes deterministic rather than reading whatever precedes a leaked allocation — e.g. construct the probe bytes explicitly, or assert the precondition over freshly-zeroed memory the test controls.

Found while auditing #8638; confirmed not caused by it (clean main with the same feature and full suite passes, and #8638 passes on 2 of 3 runs).