gc-ratchet: 7 gating rows red on main — and 04_dead_after_deep_stack / 11_collect_at_depth are NOT among them

Two separate findings from measuring the pinned gc-ratchet on current main
(ab1bd464b, perry 0.5.1464) on a darwin-arm64 host.

1. The two probes everyone believes are red are green

04_dead_after_deep_stack and 11_collect_at_depth have been carried as
"pre-existing red on main, unowned" since #7799. They are not red on current
main. Measured, shared_ci profile, 7 repeats:

• 04_dead_after_deep_stack — all nine gating cells +0.00%, bit-identical
  to the pin.
• 11_collect_at_depth — all gating cells ok; heap_used_bytes is an
  improvement (−11.99%), copied_objects 6,139 → 6,141 (+0.03%, allowance
  307), promoted_objects 0 → 0, minor_cycles 1 → 1.

Why they looked red

The six rows that were reported (04.copied_objects, and 11's
heap_used_bytes / copied_objects / copied_bytes / promoted_objects /
promoted_bytes) are exactly the six cells that #7783's re-pin already
absorbed, and every observation of them comes from a checkout that predates
that re-pin.

• The re-pin landed as db44b31b7 at 2026-08-10 18:11 UTC.
• perf(gc): predict the futile full mark-sweep instead of pricing it afterwards (retain 3.99x -> 2.54x node, retain_wide 7.01x -> 2.89x) #7799's PR body names its reference build as origin/main @ 0a2bf15bd.
  git merge-base --is-ancestor 0a2bf15bd db44b31b7 → yes, it predates the
  re-pin. Its baseline artifact therefore still carried the OLD values — and it
  had 13 probes, which is why the PR body says "all 13 probes". Main's
  baseline has 14 (14_grow_then_churn came with the re-pin).
• The only two gc-ratchet CI runs that have executed and failed in the last
  200 (31415780870, 31408538105) both started before 18:11 UTC on 08-10,
  and their Baseline column is the pre-re-pin artifact verbatim:
  04.copied_objects 565, 11.heap_used_bytes 5,097,776,
  11.promoted_objects 6,150. Their Current column is exactly what main now
  pins (605 / 5,307,584 / 0).

So both arms of #7799's A/B compared against a stale artifact and went red
identically. "Not my PR" was correct; "pre-existing on main" did not follow.

No code fix is needed for these two probes. The stale premise is the bug.

2. Seven different gating rows ARE red on main

Same run, check exit code 1:

The four heap_used_bytes deltas are near-constant in absolute terms —
+411,400 / +412,208 / +413,280 / +417,088 bytes. That is not a fixed addition
to resident heap, though: across all 14 probes the shift is bimodal, with
five probes moving down by a similarly tight −552k…−636k and five unchanged
to the byte (full table below). Four rows fire only because the gate's
[increase] direction is the one that fails; the equally large moves the other
way pass as improvements. A retention boundary moved, not a constant.

This is code, not the host, and not noise

The baseline was pinned on the bench mini (perry-macos.fritz.box, Apple M1,
8 cores, 8 GB). I measured on a different machine (M1 Max, 10 cores, 68 GB), so
"the pin is not portable off its host" had to be excluded before any of this
could be called a regression. A binary A/B settles it — same host, same
harness, same probes, same baseline artifact, only the artifact triple
(perry + libperry_runtime.a + libperry_stdlib.a) swapped:

So the pinned artifact reproduces green on all 14 probes on a machine that is
not the one it was pinned on — the shared_ci profile's claim that its gating
metrics "transfer across machine classes" holds, and the baseline is a valid
reference here. The 7 red rows are therefore code drift between 0.5.1451 and
0.5.1464.

Repeatability control: arm-main was measured twice, in separate processes,
and produced an identical red-row set both times. Within each run the
harness reports heap_used_bytes spread 0% across 7 repeats on every probe,
and correctness=pass on all 14 in both arms.

Per-probe heap_used_bytes, both arms

The shift is bimodal, not one constant — which is why only four rows fire
(the gate's [increase] direction) while five equally-large moves in the other
direction pass as improvements:

Both arms genuinely exercised the collector — 64 vs 63 total minor_cycles,
~684k copied_objects, no probe with zero minors — so the green arm is not a
vacuous pass.

Reproducing

The build is cheap (5m32s incremental for the artifact triple), so bisecting
this is a short job:

git checkout --detach <commit>
CARGO_TARGET_DIR=<tgt> cargo build --release -p perry -p perry-runtime-static -p perry-stdlib-static
cp <tgt>/release/{perry,libperry_runtime.a,libperry_stdlib.a} /tmp/arm/
git checkout main            # harness, probes and baseline must be MAIN's
PERRY_NO_AUTO_OPTIMIZE=1 PERRY_RUNTIME_DIR=/tmp/arm \
  python3 benchmarks/gc_ratchet/gc_ratchet.py measure \
    --perry /tmp/arm/perry --repeats 7 --node "$(command -v node)" --output /tmp/m.json
python3 benchmarks/gc_ratchet/gc_ratchet.py check --current /tmp/m.json --profile shared_ci

Swap only the artifact triple; keep the checked-out harness on main so the
probe set and baseline are constant across arms.

Prime suspects in the window, all collector- or layout-adjacent:
1d22273a1 (#7809, per-object layout tables, +296 lines in
gc/layout_tables.rs), 99705c937 (#7812, single-slot pointer masks),
d04cc3f29 (#7834, pointer-free typed layout stamped into the allocation
header). #7799's author measured its own branch as gating-identical to its
reference, so it is unlikely to be ad8240b5b.

3. The gate has not run on main since 2026-08-09

Independent of either finding, gc-ratchet is producing no signal:

• Every run on main since 08-10 is stuck in queued — ~103 of the last 200
  runs across all branches, with 87 cancelled, 7 pending, 1 in_progress
  and 2 failure. Zero successes in that window.
• The last successful run on main was 2026-08-09T06:52.
• gc-ratchet is not in branch protection's required contexts
  (api-docs-drift, cargo-test, compile-smoke, conformance-smoke-complete,
  lint, parity, security-audit) — that is GC follow-ups from #7733: one-way prototype latch (#7510 shape), missing positive-direction pacing test, unmeasured grow-then-churn transition, advisory-only ratchet #7737 item 4.

A gate that is not required, and whose runs never reach a runner, is dark in
both of the ways CLAUDE.md's "four ways a gate can be unable to fail" list
warns about. Both findings above went unnoticed for two days because of it.