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.

Escrita pelo modelo de indexação a partir do texto da issue.