CI gate freshness alert: 6 gate(s) have no recent successful `main` run

[proggeramlug]

The following post-merge gates have not produced a successful main run within their freshness budget.

This usually means they are starved, not broken — queued behind a merge cadence the runner pool cannot drain (#7856). Check the Actions queue depth before assuming a code failure:

gh api "repos/PerryTS/perry/actions/runs?status=queued&per_page=100" \
  -q '.workflow_runs | length'

gate	detail	why it matters
gc-ratchet.yml	last success 69.3h ago (budget 12h)	Primary defence for collector retention/evacuation accounting. Went dark 2026-08-09..08-11 while #7799/#7809/#7812/#7834/#7839 merged; #7843's seven red rows landed in that window.
tls-budget.yml	last success 58.1h ago (budget 12h)	_tlv_get_addr call-count ratchet. macOS-only by nature; cannot be relieved by moving pools.
gc-ptr-shape-off-witness.yml	last success 93.0h ago (budget 12h)	Exercises the Ptr OFF state. CLAUDE.md's kill-policy: an unexercised mode is a configuration nobody has verified.
gc-parse-churn-gate.yml	last success 93.0h ago (budget 12h)	Parse-churn layout gate.
gc-moving-witnesses.yml	last success 93.0h ago (budget 12h)	Asserts the copying minor actually moved objects -- the 'gate must assert its subject was live' arm (#7024/#7025).
llvm-inprocess.yml	last success 231.1h ago (budget 12h)	In-process LLVM backend arm; the promotion prerequisite.

Scheduling rationale and the cost it trades away: docs/src/testing/ci-gate-scheduling.md.

This issue is maintained automatically by gate-freshness.yml. It is updated in place, never duplicated, and closes itself once every gate is fresh again.

[proggeramlug]

Diagnosed. The eleven do not share one cause, and the issue's own hypothesis (starvation, #7856) is half of it.

Nine are starved and hit a #7205 relapse on the arm #7856 created. The concurrency groups key on ${{ github.event_name == 'push' && github.sha || github.ref }} — the github.sha arm is guarded on the event being push, which was correct while the main-line arm was push: branches: [main]. #7856 moved that arm to schedule:, the guard stopped matching, and the group fell through to github.ref (constant). Observed identically on all ten scheduled gates:

13:37Z schedule pending      <- blocked on the group
07:46Z schedule cancelled    <- jobs: 0
02:37Z schedule cancelled    <- jobs: 0
19:15Z schedule queued       <- holds the group, 20h in the runner queue

jobs: 0 is #7205's exact zero-execution signature. gate-freshness itself was cancelled the same way at 13:38Z.

Two are not starved at all — they are broken. gc-native-roots has never had a successful run on any branch (#7970). llvm-inprocess fails when it runs and reports green on PRs while skipping its only real job (#7971).

Queue depth is 1,529, not 100 (the snippet in this issue body pages at 100 — use -q '.total_count'). 794 are pull_request runs across 63 head branches, of which 61 no longer exist: ~790 runs, 51% of the queue, are work for already-merged PRs holding slots in front of the main gates.

Fix in #7969: groups keyed per github.run_id for non-PR events across 22 workflows; a new check_schedule_group in scripts/gc_gate_wiring_check.py (required lint) so this cannot relapse a fourth time — it found ten more workflows already carrying the same latent bug, including test.yml's nightly safety net; plus a queue reaper for the dead PR runs.

Two things #7969 deliberately does not close:

• parity and compile-smoke are required contexts whose jobs never run on a pull request (test.yml's push: is tags-only). A required context that never reports blocks the merge button forever, so every merge needs an admin bypass — which bypasses the required contexts that do work. That is upstream of this whole incident: bypass is the normal path, so a pending gate stopped looking unusual. Branch-protection state, admin only.
• gc-ratchet would not have caught perf(gc): main regressed the retain cluster 2.2-4.8x — retain now runs 2 full collections where it ran none (suspect #7901/#7902) #7965 even had it run. No gate in this repo ratchets a collection-kind count; the counter that found it (collection_kind: "full" 0 → 2) is not a gc-ratchet metric, and the two dimensions that did move (wall time, RSS) are explicitly "gating": false in the shared_ci profile CI uses. perf(gc): main regressed the retain cluster 2.2-4.8x — retain now runs 2 full collections where it ran none (suspect #7901/#7902) #7965's third ask stays open, and a fully-green freshness dashboard would not have caught it either.

Leaving this issue open for gate-freshness.yml to close itself once the gates are actually fresh.