vscode.dev/agents: opening a large Agent Host conversation repeatedly disconnects tunnel after >1 MB chat snapshot

Does this issue occur when all extensions are disabled?: Yes / N/A for the web client. This reproduces in `vscode.dev/agents` in both Firefox and Chromium, so it does not appear browser-specific or extension-specific.

- VS Code Version: `1.136.1` (`a44adf7f53e00964ab890f9f8758a334f1fc15bc`)
- OS Version: Linux x64 remote tunnel host
- Client: `vscode.dev/agents`
- Connection: VS Code tunnel
- Reproduced in: Firefox and Chromium

### Summary

Opening one specific, relatively large Agent Host conversation in `vscode.dev/agents` causes the remote Agent Host transport to disconnect and reconnect.

Other conversations on the same tunnel work normally.

The Agent Host process itself does not crash, there is no obvious memory spike or OOM, and the failure is deterministic for this particular conversation.

The browser WebSocket closes with code `1000` (normal closure), suggesting VS Code is intentionally tearing down the tunnel/session after encountering an internal transport/protocol failure.

AHP wire logs show that immediately before the disconnect, the client subscribes to the conversation's default chat with no bounded view:

```text
c2s subscribe
channel=ahp-chat://default/
params_keys=['channel']
view=None
delivery=None
```

The server then sends a single subscription response whose logged size is approximately 1.05 MB:

```text
10:44:12.043Z c2s id=409 method=subscribe
10:44:12.049Z s2c id=409 bytes=1055731 result=dict trunc=True
```

Shortly afterwards the client disconnects.

After reconnect, the exact same sequence happens again:

```text
10:44:15.463Z c2s id=416 method=subscribe
10:44:15.470Z s2c id=416 bytes=1055731 result=dict trunc=True
```

The connection then drops again.

This looks consistent with a large Agent Host chat snapshot exceeding a tunnel/relay transport frame limit.

This may be related to the transport limitation discussed in `microsoft/agent-host-protocol#138` ("RFC: Message Chunking"), which describes relayed transports with a 1 MB frame limit.

### Steps to Reproduce

1. Start a tunnel host using VS Code 1.136.1.
2. Open `vscode.dev/agents`.
3. Connect to the tunnel host.
4. Open a normal Agent Host conversation.
5. Observe that the connection works normally.
6. Switch to a specific older/larger Agent Host conversation.
7. Observe that the tunnel transport disconnects shortly after the conversation is loaded.
8. VS Code reconnects automatically.
9. The same conversation subscription/state restore can trigger another disconnect.

The behavior reproduces in both Firefox and Chromium.

### Actual Result

When opening the affected conversation, the UI reports:

```text
The terminal process failed to launch:
Transport lost (reconnecting): tunnel:.
```

The remote Agent Host log shows that the Agent Host itself remains alive:

```text
[TerminalManager] Creating terminal ...
[TerminalManager] Shell integration injected ...
[ProtocolServer] Client disconnected: , subscriptions=8
[ProtocolServer] Reconnect: clientId=, lastSeenSeq=...
[ProtocolServer] Client disconnected: , subscriptions=8
[ProtocolServer] Reconnect: clientId=, lastSeenSeq=...
```

There is no large process-memory increase and no observed Agent Host process crash.

The browser-side connection closes with WebSocket close code:

```text
1000
```

The browser console shows VS Code going through its own session close/dispose path:

```text
acceptChunk
→ fail
→ finishClose
→ closeSession
→ dispose
```

and then:

```text
[RemoteAgentHostProtocol] Reconnecting to tunnel: ...
```

### Expected Result

The conversation should load normally regardless of conversation size.

If the full chat snapshot cannot fit in a single transport frame, the client/server should either:

- request a bounded/paginated chat view,
- split/chunk the AHP message,
- or fail with a clear "message too large" error without tearing down the entire Agent Host tunnel connection.

### AHP Evidence

Immediately before the first disconnect:

```text
10:44:12.041Z c2s 298B id=407 method=subscribe
channel=claude://changeset/branch

10:44:12.042Z s2c 14474B id=407

10:44:12.042Z c2s 281B id=408 method=subscribe
channel=claude:/

10:44:12.043Z c2s 315B id=409 method=subscribe
channel=ahp-chat://default/

10:44:12.044Z s2c 16683B id=408

10:44:12.049Z s2c 1055731B id=409
result=dict
trunc=True
```

Other messages around this time are much smaller. The next largest ordinary state updates are on the order of tens or hundreds of KB.

Raw AHP JSONL line sizes for the connection containing the failure:

```text
1214124 bytes total

largest lines:
1051059
16674
15156
14484
14484
14473
14267
...
```

On the first reconnect:

```text
10:44:15.201Z c2s 856B id=414 method=reconnect
10:44:15.203Z s2c 30628B id=414

...

10:44:15.463Z c2s 315B id=416 method=subscribe
channel=ahp-chat://default/

10:44:15.470Z s2c 1055731B id=416
result=dict
trunc=True
```

The chat subscription request contains only:

```text
params_keys=['channel']
view=None
delivery=None
```

so the client is not requesting a bounded chat-history view.

### Additional Notes

The affected session has a default chat plus several subagent chats, but the Agent Host reports a stable subscription count (`subscriptions=8`). I do not see the hundreds/thousands of child subscriptions or large memory spike described in `microsoft/vscode#332501`.

Therefore this appears different from #332501.

The strongest correlation in this reproduction is the single ~1.05 MB `ahp-chat` subscription snapshot immediately preceding the transport failure.