Adopted PRs red only from a since-fixed shared-CI flake are escalated instead of updated/re-run #14500

What happened

Three adopted contributor PRs (stage/074-adopted-by-hive, in-place adoption on the contributor's fork branch) on base v5 — #14430, #14440, #14456 — sat red for hours and were escalated to stage/085-needs-decision with

stage labels: adopted PR sits with nothing the hive can push; escalating to needs-decision

and automerge skip reasons like required-check-failing:coverage.

The only thing red on them was TestPollTmuxOutputForAgent_WiresThrashBreaker, the shared-CI flake tracked in incident #14406 and fixed on v5 by #14415 (merged 2026-10-27T00:06Z, 3540e2a). Their last CI runs predate the fix, and their heads are 15–22 commits behind v5 (gh api repos/hivecommons/hive/compare/v5...<head> → behind_by 15 / 22 / 17).

So the hive adopted the PR, then concluded it had nothing to push, and parked it on a person — when either an update-branch (merge base into head) or a re-run of the failed jobs would have made it green with no human involved.

Why

escapeStalledAdoption (src/pkg/github/automerge/automerge_contributor_adopt.go) only knows two ways out of 074: re-home as a supersession, or escalate to 085 with the lane reason. The contributor lane only updates a behind branch when GitHub reports mergeable_state: behind (which needs "require branches up to date") or when the head is already green (currentBaseGate, #13634). A red head that is red only because of a since-fixed base/shared-CI flake never gets refreshed or re-run, so the stale red is read as "no fix landed".

The shared-CI/base-red deferral (#10528, #12606, base-branch-red) correctly keeps such PRs out of 070/072 while the incident is open — but once the incident closes and the base is green again, the stale head needs an action, not an escalation.

Expected

For an adopted PR (in-place, hive-owned) whose lane reason is CI-red:

1. If the failing check is green on the base branch tip (the flake / shared-CI incident was fixed on base) and the head is behind base → update-branch (merge base into head via the GitHub update-branch API; works on a fork when maintainer_can_modify).
2. If the head is up to date with base → re-run the failed workflow jobs (RerunFailedJobsByID).
3. At most one recovery attempt per (PR, head, base tip), recorded on the stage record so it never loops.
4. Only escalate to 085-needs-decision once a recovery was attempted and the PR is still red on the resulting head.
5. One structured log line per decision: msg="adopted PR recovery" with reason=update-branch | rerun-failed-jobs | skipped:<why>.

Refs

• Affected: 🐛 fix: exclude contributor tier limits from runtime self-reports #14430, 🐛 fix: changes-requested PRs no longer count as waiting on review #14440, 📖 docs: explain contributor Bob auth provider #14456
• Incident: [scanner] [shared-ci] test (agent */5) failing across hivecommons/hive — fork-PR shards on ubuntu-latest (now ubuntu-26.04 / tmux 3.6a) fail tmux restart-readiness tests #14406; fix on v5: 🐛 fix(agent): isolate thrash poller wiring test #14415