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

Bắt đầu từ các điểm vào list_pull_requests và search_pull_requests, sau đó so sánh các danh sách cho phép của trường tương ứng với các thao tác get_reviews và get_status của pull_request_read. Hoàn thành khi cả hai công cụ liệt kê đều có thể tùy chọn trả về review_decision và status_check_rollup, cho phép tạo các bản tóm tắt PR được yêu cầu mà không cần các lệnh gọi tiếp theo cho từng 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.