Phase 3 (Q7): gate CI on required status checks only

[petemoore]

Phase 3 sub-item Q7 (docs/WORKPLAN.md; resolves T5). The new CI bar.

Problem (T5)

AcceptableGiven treated every failing check as blocking, so a non-required check (optional/informational, e.g. CodeQL) made a perfectly mergeable PR look broken — stricter than the repo's own merge policy, and a contributor to chasing failures that don't gate merge.

Fix (Q7 → a)

"CI passing" ≡ "required checks passing", everywhere.

• AcceptableGiven gains a required set. Non-empty → only those checks can block; a non-required red never blocks and the agent need not chase it.
• Empty / unreadable required set → fall back to ALL checks (review M2) — a vacuously-satisfied "required passing" must never let an all-red PR read as acceptable.
• New Client.RequiredChecks(branch) reads branch protection's required-status-checks, memoised per base branch for the client's lifetime (one read per base branch per cycle, shared across the PR goroutines).
• Degrades safely: branch protection unconfigured (404), token lacks admin scope (403), or any error → empty set → all-checks gating, with a logged warning. No new hard token requirement — the tool keeps today's behaviour where it can't read protection.
• Wired into the orchestrator routing gate and both implementation CI gates (fix loop + post-squash), fetched once per run.

The Q12 no-progress floor (PR #3) automatically scopes to required checks via this — it counts whatever AcceptableGiven deems blocking.

⚠️ Operational note

To actually gate on required checks, the bot token needs admin scope to read branch protection. On petemoore/taskcluster (owner) it works; for production the deployment token would need it. Until then it transparently falls back to all-checks.

Tests

TestCIStatusAcceptableGiven gains required-gating cases: only-required-blocks, non-required-acceptable, empty→all-checks fallback, ignored-still-wins.

Local: go build/vet/test ./..., gofmt, staticcheck all clean.

🤖 Generated with Claude Code