Tell a Transient Copilot Fetch Error From the Quota Body Before Advising No Re-Request #3510

What

pr_review.py wait reads Copilot's whole-body review "Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review." as COPILOT_ERROR_POSSIBLE_QUOTA (exit 41), and advises not to re-request. That body isn't always the quota.

On ptr727/HomeAutomation-Config#1430, a 5-file develop -> main promotion, the round posted that body about 30 seconds after the pull request was created. The Copilot Actions run for it logged the real cause:

HttpError: The request could not be processed because too many files changed - https://docs.github.com/rest/pulls/pulls#get-a-pull-request: Failed to fetch PR metadata for ptr727/HomeAutomation-Config#1430

GitHub's own count for the pull request was 5 files at the time, and the same pulls/1430 diff read worked when run by hand a few minutes later. A re-request then produced a normal review. Copilot had reviewed a feature pull request in the same repository normally about 10 minutes earlier. #3507, also a promotion, got the same body at 18:51Z the same day.

Why it matters

The quota reading stops a drive and hands it to the maintainer, while this failure clears on one re-request. The two share a review body, so the body alone can't tell them apart.

Options

1. Have wait and status read the Copilot run's log for the error line (gh run view <id> --log-failed, workflow Copilot, matched to the head) and classify too many files changed as transient, allowing one re-request.
2. Keep the quota reading, but have the remedy text name the run log as the place to check first, and treat one re-request as safe where a sibling repository's latest Copilot round succeeded.
3. Leave the tool as is, and record the run-log check in the runbook (.github/copilot-instructions.md).