pull_request_read: support response field filtering

Inizia dal punto di ingresso pull_request_read e confronta il funzionamento del filtraggio dei campi in list_pull_requests e search_pull_requests. Traccia ogni metodo elencato, in particolare get_reviews e get_check_runs, per determinare come vengono rappresentati e convalidati i campi della risposta. Il lavoro è completato quando i chiamanti possono richiedere campi selezionati senza ricevere dati di payload non necessari, mantenendo la compatibilità delle chiamate esistenti.

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.