copilot-instructions: document headless bot-node-id bootstrap (avoid UI-seeding fallback on cold start)

[ptr727]

Context

Ran the GitHub Copilot PR review loop fully headless (no UI) on a downstream repo that consumes this template's runbook (ptr727/HomeAssistant-Config PR #7). Almost everything in .github/copilot-instructions.md matched actual behavior. One gap surfaced around bootstrapping the Copilot reviewer's bot node id on a brand-new PR.

What the runbook says

• "Round 1 is normally auto-seeded - poll for it before trying to self-trigger." (auto-review-on-open, may lag 1-3 min)
• To re-request on later pushes, call the requestReviews mutation with the Copilot reviewer's bot node id.
• Where to read that id (line ~59): from an existing formal review on the PR; or, if only an issue comment exists, from the issue comment author (pullRequest.comments -> author ... on Bot { id }); otherwise "request Copilot once through the GitHub PR UI" to produce a formal review to read the id from.

What actually happened (rules vs. actual)

On a freshly opened PR the head had no formal review and no issue comment yet (auto-review-on-open had not landed). To drive round 1 programmatically I needed the bot node id, but there was no source on the current PR to read it from. The only documented fallback for that state is manual UI seeding, which defeats a headless/cron run.

Specialization / suggested addition

The Copilot reviewer's bot node id is the reviewer bot account's node id and is stable across PRs (same value repo-wide, and in practice org/global). So it can be read headlessly from any prior Copilot formal review in the same repository, with no UI hand-off:

gh api graphql -f query='
{ repository(owner:"OWNER",name:"REPO"){
    pullRequests(last:20){ nodes{
      reviews(first:20){ nodes{ author{ __typename login ... on Bot { id } } } } } } } }' \
  --jq '[.data.repository.pullRequests.nodes[].reviews.nodes[]
         | select(.author.login=="copilot-pull-request-reviewer") | .author.id] | first'

Suggest documenting this as the preferred headless fallback before UI seeding, for the cold-start / round-1-lag case where the current PR has neither a formal review nor an issue comment yet. UI seeding then remains only as a last resort for a repo that has never had a Copilot review at all.

Everything else matched

For reference, these were accurate as written on this downstream repo:

• mergeStateStatus: BLOCKED on a green PR was solely unresolved review threads; the ruleset had required_review_thread_resolution: true, and resolving moved it to CLEAN.
• Auto-review is best-effort; re-requesting via requestReviews with botIds drove the loop.
• Verifying head-SHA coverage and the mergeable vs mergeStateStatus distinction held.

Filed at the request of the downstream maintainer so the template can absorb the specialization.

[ptr727]

Absorbed into the runbook via #295 (merged to develop; auto-close didn't fire since that isn't the default branch).

.github/copilot-instructions.md now documents reading the Copilot reviewer's bot node id from any prior Copilot review repo-wide (pullRequests(first: 20, orderBy: { field: CREATED_AT, direction: DESC })) as the preferred cold-start fallback, before UI seeding. UI seeding drops to a true last resort (a repo that has never had a Copilot review). The empirical stability claim was verified: BOT_kgDOCnlnWA is identical across every recent PR in HomeAssistant-Config and ProjectTemplate.

Reaches main on the next develop->main promotion.