list_pull_requests / search_pull_requests: expose review decision + combined CI status as optional fields

Commencez par les points d’entrée list_pull_requests et search_pull_requests, puis comparez leurs listes de champs autorisés aux opérations get_reviews et get_status de pull_request_read. C’est terminé lorsque les deux outils de liste peuvent renvoyer facultativement review_decision et status_check_rollup, ce qui permet d’obtenir les résumés de PR demandés sans appels de suivi pour chaque PR.

Describe the feature or problem you’d like to solve

list_pull_requests and search_pull_requests return rich per-PR metadata (state, draft, mergeable_state, timestamps, etc.) but neither exposes the PR's review decision (approved / changes requested / review required) or its combined CI/check status. Getting either today requires a separate pull_request_read call per PR (method: get_reviews and/or get_status), which doesn't scale: summarizing N open PRs costs one bulk listing call plus up to 2×N follow-up calls.

Proposed solution

Add optional fields to list_pull_requests's (and search_pull_requests's) fields allow-list:

• review_decision: the PR's overall review decision (APPROVED, CHANGES_REQUESTED, REVIEW_REQUIRED, or null) — equivalent to GitHub's GraphQL reviewDecision field, already used by gh pr list --json reviewDecision.
• status_check_rollup (or similar): the combined CI/check status for the PR's head commit — equivalent to GitHub's GraphQL statusCheckRollup field, already used by gh pr list --json statusCheckRollup.

With these available, a single list_pull_requests call per repository would be enough to classify PRs into buckets like "needs review", "blocked/CI failing", "approved and green", etc. — removing the need for any per-PR follow-up call in the common case.

Example prompts or workflows (for tools/toolsets only)

• "Give me a one-table summary of every open PR across these repos: link, title, review status, CI status" — currently requires 1 + 2N calls; with these fields, a single list_pull_requests call per repo would suffice.
• Daily/weekly PR digest bots that bucket PRs into categories (needs review / blocked / ready to merge / stale) across many repositories.
• Dashboards needing an at-a-glance "is this PR green and approved?" signal for a large PR backlog without pulling full review/check-run detail for each one.

Additional context

This mirrors what GitHub's own CLI (gh pr list --json reviewDecision,statusCheckRollup,...) already exposes in one compact call per repo. An automation agent using only the current MCP tools had to make one list_pull_requests call plus 2 pull_request_read calls per PR just to get this same information, and the resulting accumulated context (~215KB across ~80 calls for 36 PRs) was enough to make the agent's next reasoning step time out. Exposing these two fields directly on the listing/search tools would remove the need for that fan-out entirely for this class of use case.