#257 Continue the thread or run that opened a pull request when it is reviewed

Why

Responder should pick up reviews on its own pull requests, for example Greptile's inline comments, and fix them. Before this change, a separate review job handled bot comments on remediation PRs only. In production it never ran: the GitHub App wasn't subscribed to the event.

This change continues the conversation that opened the PR, instead of starting a separate job. That conversation is a tag mode thread (Slack or Linear) or an automation run.

What changes

• Origin table. pull_request_origins records which thread session or automation run opened each PR. Both open_pull_request tools write a row.
• Review webhook. pull_request_review (submitted) looks up the PR's origin and fetches the review's inline comments. It sends the review as one message:
  • Automation run: queueAutomationRunReply. If the run is busy, the message waits for the next turn.
  • Tag mode thread: a new turn on the same session. It continues the conversation via previousResponseId and resumes the paused sandbox when available. It answers in the same Slack thread or Linear session.
• Review turn checkout. The turn checks out the PR's latest commit in that repository. The checkout's baseline is the head commit, so the next push contains exactly the agent's changes, including reverts. The agent is told the review text is claims to check, not instructions.
• New tools in both runtimes: checkout_pull_request, update_pull_request and reply_to_pull_request_comment. They only work on PRs the same thread or run opened.
  • update_pull_request refuses unless the checkout is at the PR head. It commits on that head and updates the branch with force: false, so it never overwrites someone else's commits. It then moves the checkout's baseline to the pushed commit.
  • reply_to_pull_request_comment replies in the comment's review thread and can resolve it.
• Guards:
  • Reviews from bots, and from owners, members and collaborators, start a turn.
  • Reviews from other people and the app's own replies are ignored.
  • Bot reviews start at most 5 turns per PR, so two agents can't push at each other forever.
• Run page: shows GitHub review messages and pushed commits.
• Removed: the remediation-only review job (responder-pull-request-reviews-v1), its worker code and the pull_request_review_comment handler. The issue page's review-activity view stays for now; nothing writes to it anymore.

Operations

• The GitHub App must subscribe to Pull request review. Production already does.
• Migration 0069 adds one table.
• A review turn in tag mode is admitted and billed like any other tag mode turn.

Validation

• pnpm typecheck, pnpm lint (no new warnings), pnpm test (2030 passed) and pnpm build.
• New tests cover:
  • webhook routing and guards;
  • the message format;
  • push, checkout and reply behaviour, including fork, stale-head and foreign-PR refusals;
  • review turns in both runtimes;
  • the run timeline.

---

Summary by cubic

Routes pull request reviews to the thread session or automation run that opened the PR, instead of the separate review job that never ran in production. A review now becomes that conversation's next turn, and new tools let the agent check out the PR, push commits, and reply to review comments.

What changed

• pull_request_origins records which thread or run opened each PR; the pull_request_review webhook looks it up and starts a turn for the review.
• Both runtimes get checkout_pull_request, update_pull_request, and reply_to_pull_request_comment, limited to PRs the same thread or run opened.
• update_pull_request only fast-forwards from the checked-out head, so it never overwrites someone else's commits.
• Bot and owner/member/collaborator reviews start a turn; bot reviews stop after five per PR to prevent endless ping-pong.
• When reading a review comment fails, the original GitHub error message is kept so the review turn can see it.
• Removed the remediation-only review job, its queue, and its worker code.
• The run page timeline now shows GitHub review messages and pushed commits.

Operations

• The GitHub App must subscribe to Pull request review; production already does.
• Migration 0069 adds the pull_request_origins table.