Add support for resolving/unresolving PR review threads

[kulakowka]

Describe the feature or problem you'd like to solve

When working with PR review comments via MCP, there's no way to resolve or unresolve review threads programmatically. The get_review_comments method returns IsResolved status (related to #1086), but there's no corresponding mutation to change it.

Currently, to resolve review threads, users must manually go to the GitHub UI and click "Resolve conversation" for each thread.

Proposed solution

Add a new tool resolve_review_thread (or extend existing PR review tools) that wraps the GraphQL mutation:

mutation {
  resolveReviewThread(input: {threadId: "PRRT_xxx"}) {
    thread { isResolved }
  }
}

And optionally unresolveReviewThread for the reverse operation.

Suggested tool schema:

{
  "name": "resolve_review_thread",
  "description": "Resolve or unresolve a PR review thread",
  "inputSchema": {
    "type": "object",
    "properties": {
      "thread_id": {
        "type": "string",
        "description": "The node ID of the review thread (e.g., PRRT_kwDO...)"
      },
      "resolve": {
        "type": "boolean",
        "description": "true to resolve, false to unresolve",
        "default": true
      }
    },
    "required": ["thread_id"]
  }
}

How will it benefit GitHub MCP Server and its users?

• AI agents can complete PR review workflows end-to-end — after addressing review feedback, the agent can mark threads as resolved
• Batch operations become possible — resolve multiple threads programmatically instead of manual UI clicks
• Better integration with automated code review tools — bots like Copilot PR reviewer leave comments that could be auto-resolved once addressed

Use case

1. AI agent reads PR review comments via get_review_comments
2. Agent addresses the feedback (makes code changes)
3. Agent resolves the addressed threads ← not currently possible

Additional context

The thread IDs are already returned by get_review_comments in the ID field (e.g., PRRT_kwDOE5NpvM5okADy), so no additional API calls would be needed to obtain them.