Non-destructive write tools omit `destructiveHint: false`, causing conservative approval prompts

### Describe the bug

Some clearly non-destructive/additive GitHub MCP tools set `ReadOnlyHint: false` but omit `DestructiveHint: false`.

Under the MCP `ToolAnnotations` contract, `destructiveHint` defaults to `true` when omitted for a non-read-only tool. Clients that honor the conservative default can therefore treat routine additive operations as potentially destructive and require additional confirmation.

This is observable with ChatGPT using the official `github-mcp-server` over Streamable HTTP / Secure MCP Tunnel: read tools execute automatically when the app is configured with elevated / "Allow all actions" permissions, while routine write tools such as creating a branch or opening a pull request still trigger confirmation.

On desktop, the user can approve for the conversation. On mobile, the same workflow can require repeated per-call approvals.

### Examples in the current server

`create_branch` currently advertises:

```go
Annotations: &mcp.ToolAnnotations{
Title: t("TOOL_CREATE_BRANCH_USER_TITLE", "Create branch"),
ReadOnlyHint: false,
},
```

`create_pull_request` currently advertises:

```go
Annotations: &mcp.ToolAnnotations{
Title: t("TOOL_CREATE_PULL_REQUEST_USER_TITLE", "Open new pull request"),
ReadOnlyHint: false,
},
```

Both operations are additive and appear to be good candidates for an explicit:

```go
DestructiveHint: jsonschema.Ptr(false),
```

There is already precedent in the codebase: `create_pull_request_review` explicitly sets `DestructiveHint: false`, while genuinely destructive tools such as `delete_file` explicitly set `DestructiveHint: true`.

### Expected behavior

Clearly additive write tools should explicitly advertise `DestructiveHint: false` instead of inheriting the MCP default of `true`.

It may also be worth auditing other write tools and explicitly classifying them rather than relying on the default. Tools whose behavior depends on the requested method or which can overwrite/delete existing state should remain conservative.

### Why this matters

This does not change security enforcement; MCP annotations are hints. But clients use those hints to drive confirmation UX.

Missing `destructiveHint: false` makes safe additive operations indistinguishable from potentially destructive writes to conservative clients, which creates significant approval friction in agentic workflows.

### Environment

* `github-mcp-server` v1.12.1
* Streamable HTTP transport
* ChatGPT custom MCP app over OpenAI Secure MCP Tunnel
* App permission set to elevated / Allow all actions
* Read operations do not prompt; routine write operations do

### Related issues

* #798 — fine-grained confirmation settings for write actions
* #2723 — `label_write` delete missing `DestructiveHint: true`

Start by locating the registrations for create_branch and create_pull_request, then compare their ToolAnnotations with create_pull_request_review and delete_file. Audit the other write tools mentioned in the issue, explicitly marking clearly additive operations non-destructive while keeping overwrite or delete behavior conservative. Done means the relevant annotations are classified and the existing tool tests pass.

Written by the indexing model from the issue text.