Clarify that pull_request_review_write create without event creates a pending review

Cerca pull_request_review_write nella definizione dello strumento ed esamina la relativa annotazione del titolo e la descrizione breve. Aggiorna la formulazione visibile all'utente in modo che method: "create" senza event indichi chiaramente una review in sospeso e non inviata; il comportamento esistente dello strumento singolo deve rimanere invariato.

Problem

When using the pull_request_review_write tool from a client like Claude Code to "create a review," the server correctly creates a pending review if the event parameter is omitted. However, the user-facing title/description does not clearly indicate that this call only creates a pending review and does not submit it.

Current behavior

• Tool name: pull_request_review_write
• Title: "Write operations (create, submit, delete) on pull request reviews"
• Description (in code) already says:

  create: Create a new review of a pull request. If "event" parameter is provided, the review is submitted. If "event" is omitted, a pending review is created.

Clients often show only the short title or a condensed description, so users just see that a review is being "created," not that it's pending only.

This is confusing when watching MCP tool calls in the UI: the first call to pull_request_review_write looks like it "created a review," but in GitHub it is actually just opening a pending review, which then gets line comments via add_comment_to_pending_review, and later is submitted with pull_request_review_write method: "submit_pending".

The underlying workflow is correct; the wording is misleading.

Requested change (minimal, backwards compatible)

Update the Title annotation for pull_request_review_write to make "pending" explicit, e.g.:

• "Create pending / submit / delete pull request reviews", or
• "Pending review create / submit / delete for pull requests"

Optionally, emphasize in the short description that method: "create" without event creates a pending review and does not submit it.

This keeps the existing single-tool design (no new tools, no API change) but makes the behavior much clearer to users of MCP clients that only surface the short title/description.