Fork review follow-up never dispatches: GitHub reports base repo as head_repository #2133

Problem

A review on a fork PR does not update the review-state label until another event reconciles the PR (CI completion, a CodeRabbit comment, or the cron sweep).

Example: PR #1662 (fork PierrunoYT). A maintainer submitted CHANGES_REQUESTED on 2026-10-21 02:44:07Z. The label stayed awaiting-maintainer instead of awaiting-author.

Root cause

label-pr-review-state-fork-review-followup.yml (added in #2088) should dispatch a privileged reconcile run after a read-only fork review run. It never does.

The follow-up reads workflow_run.head_repository. For pull_request_review runs, GitHub sets this field to the base repository (Zoo-Code-Org/Zoo-Code, fork: false), even for fork PRs. This causes two defects:

1. Guard skips every run. if (run.head_repository && run.head_repository.fork === false) return; matches all review runs. Five follow-up runs between 2026-10-20 13:53Z and 2026-10-21 03:05Z logged Ignoring same-repository pull_request_review run. No workflow_dispatch run of label-pr-review-state.yml exists after 2026-10-18.
2. PR lookup would fail. The fallback queries head=<head_repository.owner>:<head_branch>. That is Zoo-Code-Org:fix/1591-... and returns 0 PRs. The query with the real fork owner returns the PR.

The label workflow itself detects forks correctly. isReadOnlyRun reads context.payload.pull_request.head.repo, which is the real fork.

Evidence

• Sampled 12 recent pull_request_review runs of the label workflow. All 12 report head_repository = Zoo-Code-Org/Zoo-Code, fork: false. For fork PRs pull_requests is empty. For same-repo PRs it has one entry.
• Run 39534658962 (the fix(openai): count compatible cache reads #1662 review): read-only job logged fork PR on a read-only run. Its follow-up logged Ignoring same-repository pull_request_review run.
• GET /commits/{head_sha}/pulls returns [] for fork SHAs. Tested on 3 fork review runs. Do not use it.
• Listing open PRs and matching head.sha finds the correct PR. Tested on fix(openai): count compatible cache reads #1662 (029ea76b), Stop repetitive reasoning streams before provider timeout #1904 and Fix interrupted child redelegation #1905. 229 PRs are open now, so this is 3 pages.
• src/services/__tests__/fork-review-followup-workflow.test.ts builds fork runs with head_repository.owner.login = "contributor" and fork: true. GitHub never sends this for this event. Test "ignores a same-repository review run" (line 172) locks in the guard.

Proposed fix

1. Remove the fork === false early return. A dispatch for a same-repo PR is idempotent. The event check already stops the chain after one hop.
2. When run.pull_requests is empty, list open PRs and keep those where head.sha === run.head_sha, head.ref === run.head_branch and the base repo is this repo. Do not use head_repository.owner.
3. Fix the test fixture so fork runs report head_repository as the base repo with fork: false. Replace the same-repo test with one that expects a dispatch.
4. Check the duplicate lookup in label-pr-review-state.yml (resolve PRs to reconcile, workflow_run branch). It uses the same owner-and-branch query. Fix it the same way if the CI workflow_run payload has the same shape. The comment says to keep both copies in sync.

Acceptance

• A CHANGES_REQUESTED review on a fork PR changes the label to awaiting-author within one workflow cycle, without waiting for the sweep.
• The follow-up test uses a payload copied from a real run.

Impact

Labels on fork PRs lag until the next sweep (about every 3 hours, not hourly) or another trigger. Related: #2046, #2049, #2086, #2088.