fix(cli): select newest blocking PR review (BRIX-1809)

[quay-worker]

Summary

• Select the newest CHANGES_REQUESTED review for the current PR head when review commit metadata is available, instead of trusting latestReviews order or a global timestamp pick.
• Preserve review node id and submitted head SHA fallback from the full reviews projection.
• Add adapter and done-state polling regressions for stale old review plus fresh current-head feedback, including newer stale feedback masking older current-head feedback.

Deployment Steps

✅ No manual deployment steps needed, will be fully operational after automated CI deployment.

Test Plan

Pre-merge checklist

• bun run typecheck:cli
• bun test packages/cli/tests/adapters/test_github_adapter_review_id_empty_latest_reviews.test.ts
• bun test packages/cli/tests/review/test_review_feedback_schedules_non_budget_respawn.test.ts
• bun run test:cli

Post-deployment verification

• Confirm an open done-state Quay task requeues when a fresh current-head CHANGES_REQUESTED review arrives.

[linear]

BRIX-1809

[quay-reviewer]

Review Findings

Blocking

🔴 [1] Newer stale reviews can still mask actionable current-head feedback
The selector now chooses the newest CHANGES_REQUESTED by submittedAt across all latestReviews rows, then the done-state guard rejects that single pick if its submitted head SHA is not the PR head. That still drops valid feedback when a reviewer submits a newer review against a superseded commit while another unacted CHANGES_REQUESTED review exists on the current head: extractLatestReview returns the stale review at github.ts:1708-1726, and hasActionableReviewFeedback then rejects it at tick.ts:4324-4326 without considering the current-head review. Select the newest blocking review whose commit matches headRefOid when commit metadata is available, only falling back to unconstrained timestamp selection when the head association is unknown. Add a regression with newest stale old-head feedback plus older unacted current-head feedback so this cannot regress.

Review-feedback retrigger logic must select the newest actionable review for the current PR head before applying dedupe, because stale review metadata can otherwise mask valid feedback and strand open PRs.

Non-blocking

None.

[quay-reviewer]

lgtm!