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

### 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.

Start at the list_pull_requests and search_pull_requests entry points, then compare their fields allow-lists with pull_request_read operations get_reviews and get_status. Done means both listing tools can optionally return review_decision and status_check_rollup, allowing the requested PR summaries without per-PR follow-up calls.

由索引模型根据 Issue 内容生成。