Remote MCP calls to the Copilot-hosted GitHub MCP server fail (crush)

### Describe the bug

Remote MCP calls to the Copilot-hosted GitHub MCP server (`https://api.githubcopilot.com/mcp/`) fail during tool listing with a "session not found" error, specifically on the `subscriptions/listen` request, which is sent with an empty session ID. This started abruptly today - first occurence at `2026/08/20 14:29:20` UTC+2 - with no local config or token changes, and reproduces consistently across multiple client (Crush) versions (0.88.1, 0.89.0 and 0.90.0), so it does not appear to be a client-side regression. I have been using the remote MCP calls for the past 2-3 weeks successfully.

Notably, the `initialize` response's `capabilities.resources` object is empty (`{}`) — no `subscribe: true` is advertised — yet the client attempts a `subscriptions/listen` call regardless, which then fails with the empty-session error and tears down the connection.

I've isolated this to the server/session layer with a manual curl reproduction (see below, and double check it as I asked my local AI to give me the curl commands for this investigation): a raw `initialize` -> `notifications/initialized` ->`tools/list` sequence against the same endpoint, with the same PAT, completes successfully and returns a valid session ID. This suggests the issue is specific to how the session ID is being handled/propagated for the `subscriptions/listen` call path, not with authentication or the basic MCP handshake.

### Affected version

I don't know which version the remote is using. But I can see in this morning crush logs that it triggers no error, and then in the early afternoon and until now I have the errors. So whatever changed during that time period.

The curl initialise post returned a version, I hope this is relevant for you:

"version":"github-mcp-server/remote-cea154657bcbd68eeea95ecedde676a3278e2c30"

### Steps to reproduce the behavior

1. Configure an MCP client (I used Crush, versions 0.90.0, 0.89.0, and 0.88.1, all reproduce identically) to connect to `https://api.githubcopilot.com/mcp/` via HTTP transport with a valid PAT in the `Authorization: Bearer` header. (see below)
2. Have the client perform the standard MCP handshake (`initialize` → `notifications/initialized` → `tools/list`).
3. Observe the client fail while listing tools, with the underlying transport attempting `subscriptions/listen` and receiving a "session not found" error with an empty session ID.

I'm using the following `.crushrc` configuration in my local project:

```
mcp add github --type http --url "https://api.githubcopilot.com/mcp/" \
--timeout 10 --header Authorization "Bearer $GH_PAT"
```

Before calling `crush` I load my GitHub PAT in the GH_PAT env variable. I'm using a fine grained access token (which is not expired):

Repository access: openporte/openporte
Repository permissions: Read access to Dependabot alerts, License compliance alerts, code, code quality, commit statuses, issues, metadata, pull requests, and security events

### Expected vs actual behavior

**Expected:** When starting crush, the MCP status for GitHub should be green.

**Actual:** When starting crush, the MCP status for GitHub is red with an error. The message is truncated in the TUI: `GitHub error: connection cl...` the rest isn't visible. But I have a log message which is in the next section.

### Logs

This is the relevant line from my crush log (the first time it broke):

```
2026/08/20 14:29:20 ERRO Error listing tools error="connection closed: calling "tools/list": client is closing: sending "subscriptions/listen": failed to connect (session ID: ): session not found" source=github.com/charmbracelet/crush/internal/agent/tools/mcp/init.go:552
```

And the previous startup was successful with:
```
2026/08/19 02:34:32 INFO Initializing MCP clients source=github.com/charmbracelet/crush/internal/agent/tools/mcp/init.go:294
```

Crush was running the whole time between this two dates. I restarted crush this afternoon because I added a new provider to its config. In my crush sessions this morning and yesterday, I referenced GitHub issues which were read from crush.

And from curl, `initialize` response capabilities (redacted of unrelated fields):
```json
{"capabilities":{"completions":{},"prompts":{},"resources":{},"tools":{}}, "protocolVersion":"2025-06-18"}
```
Note `resources` is empty; no `subscribe` flag advertised.

Start with the manual curl handshake and the Crush MCP entry points in internal/agent/tools/mcp/init.go, especially the logged lines around 552 and 294. Compare session handling for subscriptions/listen with the initialize capabilities response, then reproduce against the remote endpoint. Done means tool listing succeeds without an empty-session error and Crush reports a green GitHub MCP status.

Vom Indexierungsmodell aus dem Issue-Text verfasst.