`add_issue_comment`, `update_issue`, and `get_issue` reject valid integer `issue_number`

### Summary

Three endpoints that take `issue_number` as a required parameter consistently fail when invoked with an integer, even though the tool schema declares `issue_number` as `number`. Other endpoints on the same server that take integer parameters work correctly, and the failure survives reconnecting the MCP server.

### Affected tools
- `add_issue_comment`
- `update_issue`
- `get_issue`

### Unaffected tools (for comparison, same session, same repo, same auth)
- `create_issue` — succeeds (does not take `issue_number`)
- `list_issues`, `search_issues` — succeed
- `create_branch`, `create_or_update_file`, `push_files`, `create_pull_request` — all succeed, including calls with integer fields like `milestone`

### Reproduction

1. Any repo the caller can write issues on.
2. Call, e.g.:
```json
{
"tool": "add_issue_comment",
"arguments": {
"owner": "",
"repo": "",
"issue_number": 11,
"body": "test"
}
}
```
3. Call fails. Retrying multiple times, including after fully reconnecting the MCP server, reproduces the failure.
4. `create_issue` against the same repo in the same session succeeds, ruling out auth, permissions, and rate limiting.
5. Reproduced across at least two independent sessions on the same day.

### Expected
Comment is posted / issue is updated / issue is fetched, matching a direct REST call to `POST /repos/{owner}/{repo}/issues/{issue_number}/comments` (etc.).

### Actual
Call is rejected before it reaches GitHub. The failure pattern is consistent with `issue_number` being serialised as a string somewhere in the request pipeline and then rejected by the server's own integer validation.

[TODO fill in with error string on next occurrence]

### Hypothesis

The three broken endpoints are exactly the ones where `issue_number` is templated into a URL path segment (`/repos/{owner}/{repo}/issues/{issue_number}[/comments]`), whereas the working endpoints pass their integers in the request body or query string. Likely culprits:

- A path-parameter substitution step stringifies the value before an internal validator runs.
- A schema-validation layer runs *after* path substitution and sees a string where a `number` is required.

Anywhere `issue_number` is interpolated into a URL is worth checking first.

### Affected version
- MCP server: GitHub MCP http server
- Transport: stdio.
- Client: custom provider

[Please run ` docker run -i --rm ghcr.io/github/github-mcp-server ./github-mcp-server --version` and paste the output below](https://github.com/github/github-mcp-server/pkgs/container/github-mcp-server/993100275?tag=sha256-27bf6a6927e2a9b0d3c96e6689f6dd6dcd0cd801e59d1916f2c324703b84e1da.sig)
### Workaround
None from the client side; the caller cannot influence how the server serialises the parameter. Affected users have to fall back to the GitHub REST API directly or edit the issue in the web UI.

Start with the implementations and request-validation paths for add_issue_comment, update_issue, and get_issue, focusing on issue_number interpolation into URL paths. Reproduce the calls with an integer and compare them with a working integer parameter such as milestone. Done means integer issue_number values pass validation and reach the corresponding GitHub REST endpoints, with regression coverage for all three tools.

Written by the indexing model from the issue text.