[BUG] Preserve awaiting-author until maintainer re-review

[edelauna]

Problem

The PR review-state workflow can remove awaiting-author before the author completes the required re-review step.

The workflow only considers human maintainer reviews attached to the current head SHA. After an author pushes fixes or merges the base branch, an older CHANGES_REQUESTED review no longer affects label selection. If CI passes and CodeRabbit approves the new head, the workflow can incorrectly select awaiting-maintainer even though the author did not re-request review from the blocking maintainer.

This behavior conflicts with the contributor instruction to re-request review from the reviewer after changes are ready.

Example

PR #1119 shows this failure mode.

• A human maintainer submitted CHANGES_REQUESTED.
• Later commits changed the head SHA.
• The workflow ignored the older human review because it was not attached to the current head SHA.
• CI and CodeRabbit could then move the PR to awaiting-maintainer without an explicit re-request.

Relevant evidence:

• The current-head filter appears near .github/workflows/label-pr-review-state.yml.
• The re-request instruction appears near CONTRIBUTING.md.

Expected behavior

Keep awaiting-author after a human maintainer requests changes until one of these events occurs for that same maintainer:

1. The PR author explicitly re-requests review.
2. The maintainer submits a newer review.
3. GitHub dismisses the blocking review.

Do not clear the blocker because another maintainer approves. Keep awaiting-author while any human maintainer blocker remains.

Use this label precedence:

1. has-conflicts
2. CI pending or failed
3. awaiting-author
4. awaiting-coderabbit
5. awaiting-ready
6. awaiting-maintainer
7. No state label after final approval

Proposed design

• Create one durable blocker for each human maintainer who submits CHANGES_REQUESTED.
• Preserve each blocker across author pushes, base updates, CI runs, and CodeRabbit reviews.
• Reconstruct blocker state from paginated issue timeline events and review history.
• Require the review-request event actor to match the PR author.
• Require the requested reviewer to match the blocking maintainer.
• Do not let team review requests clear an individual blocker.
• Add review_request_removed as a reconciliation trigger.
• Do not treat review-request removal alone as evidence that clears a blocker.
• Keep current-head freshness rules for approvals and CodeRabbit reviews.
• Preserve awaiting-author when reconstruction is incomplete.

Acceptance criteria

• An author push without a re-request keeps the original maintainer blocker.
• An explicit author re-request to the same maintainer clears that blocker.
• A base-only merge keeps the blocker.
• A current-head CodeRabbit approval does not clear a human blocker.
• Another maintainer approval does not clear the original maintainer blocker.
• A newer review from the original maintainer clears or replaces that maintainer's blocker according to its state.
• Multiple maintainer blockers remain independent, and awaiting-author remains until all blockers clear.
• A dismissed blocking review clears its blocker.
• Timeline and review pagination do not change the result.
• Reordered or duplicate events produce the same blocker state.
• review_request_removed triggers reconciliation but does not clear a blocker by itself.
• Incomplete history reconstruction preserves awaiting-author.

Risks

GitHub does not expose a durable field that directly records an author re-request after a specific review. The workflow must correlate timeline events and review history carefully.

Missing pages, delayed events, duplicate delivery, or reordered events can create false transitions. The workflow must use idempotent reconstruction and fail closed when evidence is incomplete.