gc-ratchet baseline stale on main: 31 cells breached on main's own scheduled run #11210

The committed gc-ratchet baseline is stale on main: the gc-ratchet workflow fails on main's own scheduled run.

Evidence: main's scheduled gc-ratchet run 35956358165 (2026-09-24 04:36Z) and #10960's run 35974730496 report the same 31 breached cells across 11 probes (01, 02, 04, 05, 06, 07, 09, 10, 11, 12, 14), identical apart from timestamps. 14_grow_then_churn accounts for 7 of them (for example copied_objects 330 in the baseline vs 896 measured). On that cell every deterministic counter is identical between main and #10960, so the drift happened on main, not in that PR.

The fix is a selective re-pin. Per the ratchet README, each cell's move has to be attributed to the main commit that caused it, which means bisecting from the pin commit, not blanket-regenerating. Until then, gc-ratchet is red for every PR that runs the extended tier, which makes it one of the "a gate that is always red cannot fail" gates.

hello-world-perf's lane has offered to do the bisect-and-repin.