issue_write update (state: closed) hangs — mutation succeeds but no response is ever returned

## Summary

`issue_write` with `method: "update"` and `state: "closed"` performs the GitHub mutation but **never returns a JSON-RPC response**. The issue is successfully closed (confirmed in the GitHub UI), but the MCP tool call hangs and the client must time out or be interrupted. Other `issue_write` update calls (e.g. editing the body or labels without a state change) return normally within a second or two.

## Environment

- **github-mcp-server**: `1.0.3` (commit `4bded57e02e9346cb1fd595156e07dea51f0fb29`)
- **Transport**: stdio (`github-mcp-server stdio`)
- **Auth**: PAT via `GITHUB_PERSONAL_ACCESS_TOKEN`
- **OS**: Linux (Ubuntu, Node 24 MCP client)
- The server is reached through a proxy (callmux), but the symptom is at the JSON-RPC layer: the request is dispatched, the GitHub mutation lands, and no `tools/call` response message is ever sent back. The proxy only observes a pending call with no reply.

## Reproduction

Call `issue_write` with a state transition to closed plus labels:

```json
{
"method": "update",
"owner": "",
"repo": "",
"issue_number": 158,
"state": "closed",
"state_reason": "completed",
"labels": ["infra", "fixed"]
}
```

## Expected

The tool returns the updated issue (URL / number / state) within a couple of seconds, the same as any other `issue_write` update.

## Actual

- The issue **is** closed on GitHub (the underlying API mutation succeeds).
- No response is returned to the MCP client — the `tools/call` never completes.
- The client hangs until it hits its own call timeout (or is manually interrupted).

## Impact

Because the call never returns, an agent driving the server has no way to know the operation succeeded. It either blocks for the full client-side timeout window or interrupts and may incorrectly treat the close as failed (and, worse, retry it). A consistently-returned response — even just the updated issue object — would resolve this.

## Notes / guesses

The hang appears specific to the **state-change-to-closed** path (a plain label/body update on an open issue returns fine). It looks like the update handler may complete the mutation but block or fail to write the response when `state: "closed"` (possibly combined with `state_reason` / `labels`) is part of the same call. Happy to capture stderr / a protocol trace if that would help narrow it down.