Feature request: batch-fetch pull request review comment threads for an explicit PR list

先阅读现有的 pull_request_read 和 get_review_comments 行为，然后查看仓库中关于更新 script/generate-docs 和 toolsnap 的约定。定义并记录有界的 PR 数量，以及缺失 PR 或 404 PR 的处理行为，添加测试，并更新生成的文档或 toolsnap 构件。显式列表的批处理行为经过测试并记录后，即视为完成。

Problem

Today, pulling inline review threads for multiple PRs means N separate pull_request_read calls (get_review_comments per PR). For agent workflows (team playbooks, review digests, distilling recurring conventions into docs or rules), that is slow, error-prone, and uses more API round-trips than necessary.

Proposed solution (v1)

Add a tool (name up to maintainers) that accepts:

• owner, repo
• pull_numbers: array of integers (bounded, e.g. configurable max such as 20–50)
• Optional pagination parameters consistent with existing get_review_comments behavior

Behavior: For each PR number, return the same structured data as today’s per-PR get_review_comments (threads + metadata such as resolved/outdated), keyed by pull_number.

Explicit non-goals (v1):

• No semantic ranking, clustering, or “top comments” inside the server.
• No implicit full-repo scan; the caller supplies an explicit list (e.g. from search_pull_requests / list_pull_requests / git).

Why this matters

• Documents a single supported pattern for agents: select PRs → one batch read → summarize offline.
• Reduces N+1 calls for engineering hygiene (guidelines derived from real review text).

Acceptance criteria (suggestion)

• Documented max PR count and behavior for missing/404 PRs (partial success vs fail-all—pick one and document).
• Tests + script/generate-docs / toolsnap updates per repo conventions.

Related issues

• Reply to review comments (still one thread at a time today): https://github.com/github/github-mcp-server/issues/1323
• Copilot suggestion changesets not in API (platform/API gap): https://github.com/github/github-mcp-server/issues/2235
• Companion (batch PR metadata for changelogs): https://github.com/github/github-mcp-server/issues/2302

Note

We are happy to prototype a PR if maintainers agree on v1 scope (explicit pull_numbers[], caps, and error semantics).