Three pushes produced no synchronize event and nothing detected it: a PR with zero check-runs reads as queued #16091

Problem

On 2026-09-08 evening, three pushes across three branches landed on the remote
but produced no synchronize event, so no pull_request-triggered workflow
was ever dispatched for them. The PR objects kept pointing at the previous head.

Nothing reported this. The PRs did not look red or stalled — they looked like
PRs whose CI had not started yet, which is indistinguishable from a busy queue.
One of them sat that way for roughly forty minutes before anyone noticed, and it
was noticed by a session comparing a PR's headRefOid against its branch tip,
not by any check in this repository.

Evidence

Not the Actions backlog: the newest workflow run in the repository at the time
was created at 23:32Z, after all three pushes. Actions was scheduling normally
for every other ref.

No common commit shape. This was checked specifically to avoid filing a
mechanism that does not hold:

• 8ce29f3af8 — a merge, parents d5a5d364b4 (human) + b58af33ea0 (github-actions[bot])
• eb15943247 — single parent 1f5fee13f0, human
• 9c98191f4c — single parent 27d2058969, human

An initial hypothesis that the common factor was "a push whose parent is a
commit Actions had just written" describes exactly one of the three and is
recorded here only so nobody re-derives it.

All three recovered on a nudge, so there is no standing outage:

• fix(redis): name the Stack unit everywhere it is operated (#16071) #16072 — gh pr close + gh pr reopen → 35 runs on the same tip, immediately
• feat(coordination): project work claims onto the bus and expose the claim table (#15949) #16085 — an empty commit + push → 35 runs, immediately

What this issue is actually for

The delivery failure is GitHub-side and not ours to fix. The detection gap is
ours, and it is the part worth closing: a PR whose head has zero check-runs is
currently indistinguishable from a PR whose checks are queued, and both render
as "waiting".

This is the same shape as two other gate defects found the same evening — a
skipped required context from a superseded run satisfying branch protection,
and a batching gate that cannot see a recorded dependency edge (#16086). In each
case a check reports two different states identically, and the benign reading is
the one that wins.

Proposal

A check that compares a PR's headRefOid against its branch tip, and the tip's
check-run count against zero, and says so plainly. It does not need to be a
required context — surfacing it is the whole value, because the recovery is a
close/reopen that takes seconds once someone knows.

Close/reopen is the preferred recovery: it fires reopened, which the workflows
already trigger on, and leaves no artefact on the branch. An empty commit works
but leaves a permanent chore: re-trigger CI commit that says nothing about the
change.

Acceptance criteria

• A PR whose headRefOid differs from its branch tip is reported as stale,
  distinctly from "checks pending"
• A PR whose head commit has zero check-runs, where the repository has
  scheduled runs more recently, is reported as not scheduled rather than
  as waiting
• The two conditions are reported separately — they have different causes
  and the same recovery, and conflating them is how the second went unseen
• Tests cover: stale object, zero-check-runs, and a genuinely queued PR that
  must NOT be flagged — the third asserted, since a detector that fires on
  healthy PRs will be ignored within a day
• The recovery (close/reopen) is named in the output, not left to be looked up

Notes

Filed with a deliberately narrow claim. The mechanism behind the dropped events
is unknown and a guess in this issue would be expensive to unpick later. What is
established: three pushes, three branches, no common commit shape, zero events,
and immediate recovery on a nudge.