pr-fixup

# PR Fixup Use this workflow directly in the user-started primary conversation. Do not launch a verifier, implementer, or other remediation subagent. A read-only `pr-poller` is the sole exception: launch it only when the user explicitly asks to wait for or monitor PR updates. For a cost-controlled workflow, the user may switch the same conversation to the lower-cost implementation/test model before starting CI remediation. Use `gh` by default; auth or transport errors leave state unknown, never clean. If connector tools are available, use structured PR/check/thread data; avoid dumping full HTML/diffs. Map GraphQL thread IDs to REST comment IDs before replies, and refresh current-head state after pushes and review aggregation. ## Pipeline Create a visible checklist: 1. Gather PR state 2. Resolve an authorized PR merge conflict 3. Fix failing CI checks 4. Triage every review thread 5. Apply valid fixes and record every disposition 6. Commit, rerun affected checks, and push 7. Re-check the new head 8. Report ## 1. Gather PR State Before the first GitHub call, obtain any network approval required by the runtime. If the runtime denies access, stop until the user authorizes access. Run `scripts/pr-state --summary <PR>` and `scripts/pr-resolve list <PR>`. Load [review-evidence.md](references/review-evidence.md) for snapshot fields, review classification, hidden threads, and access fallbacks. For cross-repository PRs, use the snapshot's delivery fields as the push target. Th...