pull_request_read: support response field filtering

### Describe the feature or problem you’d like to solve

`list_pull_requests` and `search_pull_requests` both support a `fields` parameter to trim response size to only what the caller needs. `pull_request_read` has no equivalent for any of its methods (`get`, `get_diff`, `get_status`, `get_files`, `get_commits`, `get_review_comments`, `get_reviews`, `get_comments`, `get_check_runs`) — every call always returns the full, maximally verbose payload.

This is a significant problem for `get_reviews` and `get_check_runs` specifically:
- `get_reviews` returns the full review `body` for every review, even when the caller only needs `state` and `user.login` to compute a review decision. Bot-generated reviews (e.g. Copilot code review) can each be several KB of markdown.
- `get_check_runs` returns a fully itemized list of every check run (name, URL, timestamps, etc.) even when the caller only needs an overall pass/fail signal — `get_status` already provides that more cheaply, but doesn't help when a specific failing check's name is needed.

In practice, this forces callers who just want a compact per-PR summary (review decision + CI status) into fetching and carrying far more data than necessary.

### Proposed solution

Add a `fields` (or `select`) parameter to `pull_request_read`, consistent with the existing pattern on `list_pull_requests`/`search_pull_requests`:
- For `get_reviews`: allow selecting a subset of `{id, state, user, submitted_at, body}` per review, defaulting to omit `body`.
- For `get_check_runs`: allow a `fields` filter over per-check fields (name, conclusion, url, timestamps, etc.).

This lets callers request only the compact signals they need, keeping response size proportional to what's actually useful — the same benefit `fields` already provides on `list_pull_requests` and `search_pull_requests`.

### Example prompts or workflows (for tools/toolsets only)

- "Summarize the review and CI status of every open PR across these 7 repositories" — an agent lists PRs per repo, then for each PR calls `pull_request_read` with `method: get_reviews, fields: [state, user]` and `method: get_check_runs, fields: [name, conclusion]` to build a compact status table, instead of ingesting full review bodies and full check-run details it never uses.
- Any dashboard/digest/reporting tool that needs "is this PR approved and green?" for many PRs at once, without paying the cost of full review text and full check-run metadata per PR.
- Bulk PR triage workflows that classify PRs into buckets (needs review / blocked / ready to merge / stale) based only on review state and CI pass/fail, run across many repositories in a single pass.

### Additional context

We hit this concretely in an automation agent that summarizes open PRs across several repositories into a digest: listing PRs, then calling `get_reviews` + `get_check_runs` per PR to classify each one, accumulated roughly 660KB of conversation context across ~110 tool calls (full unfiltered payloads for each call). The agent's next step then timed out entirely before producing any output. A single compact call per repository via GitHub CLI's `gh pr list --json reviewDecision,statusCheckRollup,...` returns equivalent information in a fraction of the size, precisely because it lets the caller select only the fields it needs — the same capability `pull_request_read` is missing.

Start at the pull_request_read entry point and compare how fields filtering works in list_pull_requests and search_pull_requests. Trace each listed method, especially get_reviews and get_check_runs, to determine how response fields are represented and validated. Done means callers can request selected fields without receiving unnecessary payload data, while existing calls remain compatible.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.