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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.