diag: [gc-primitive-dispatch] string_wrappers counter has no writer on main since #9810/#9814 (reads 0 unconditionally)

[proggeramlug]

What

[gc-primitive-dispatch] …: string_wrappers=… index_properties=… (emitted by report_primitive_dispatch in crates/perry-runtime/src/gc/diag_sites.rs) can no longer report a non-zero string_wrappers count on main (35c36f425).

Its only writer was diag_string_wrapper_materialized, called from inside install_string_wrapper_indices. #9810/#9814 made string-wrapper indices virtual and deleted that loop, taking the writer with it. STRING_WRAPPERS is now read and never written, so the wrappers > 0 branch of report_primitive_dispatch is unreachable and the line silently reads 0 under PERRY_GC_DIAG=1.

Why it matters

A counter that cannot fire greps identically to a workload that does not trigger it. #9795 cites this line as its headline evidence (string_wrappers=…, index_properties=99,008); on main the index_properties half has already landed via #9810/#9814 and the other half has no instrument. Anyone using the line to evaluate a string-wrapper change on main gets a false negative.

Found by the rebase of #9795 onto 35c36f425 (the rebased tree's positive-control test still moves, because the test measures the surviving wrapper/globalThis/closure-clone cost directly, not via this counter).

Fix

Either re-attach a writer at the site that now materialises a wrapper (the virtual-index path's fallback, if one exists), or delete the STRING_WRAPPERS site and the wrappers > 0 branch so the diag does not print a number that cannot be non-zero. A check_test_registration.py-style gate for diag sites — every AtomicU64 site in diag_sites.rs must have at least one writer outside diag_sites.rs — would catch the next one.

Related: #9795, #9810, #9814. Fifth instance today of a check that cannot fail (see the campaign notes).

https://claude.ai/code/session_014knX724SYDogwzsXybCGxp