Remote-SSH: a stale 'code agent host' supervisor keeps serving new windows, so no agent session ever loads

Type: Bug

Agent sessions never load in any Remote-SSH window. The session list stays empty and nothing in the UI explains why.

VS Code: 1.137.0-insider, commit `af195aabe861b9d99fcb322904793322ae7f0952`
Client: macOS. Remote: Linux.

### What actually happens

The AHP handshake with the remote agent host fails, so the connection is never established. From the window's `renderer.log`:

```
[AgentHost:remote] Initializing (remoteAuthority=ssh-remote+...)
[AgentHost:remote] Connecting to remote agent host...
[RemoteAgentHostProtocol] Request 1 failed: {"code":-32005,"message":"Client offered protocol versions
[0.9.0, 0.7.0, 0.6.0, 0.5.2, 0.5.1], none of which are compatible with this server's version 1.0.0
(server accepts ^1.0.0)."}
[AgentHost:remote] Connect failed
```

### Why the versions don't match

Remote-SSH installed the correct server for my client commit — the Remote-SSH log confirms `Using commit id "af195aab..."` and the server process on the remote is from that exact commit. But the server does not talk to its own agent host. It bridges to one that was already running:

```
[server] [AgentHostChannel] Registered IPC channel 'agentHostProxy' (upstream: 127.0.0.1:36449)
[server] [AgentHostChannel] Opening upstream to 127.0.0.1:36449
```

Port 36449 belongs to a standalone `code agent host` supervisor that has been running on that machine since **August 21** — 12 days. Its binary has already been deleted from disk by the CLI's own cleanup:

```
5156 Fri Aug 21 12:37:08 2026 ~/.vscode-server-insiders/code-insiders-8a537d3a1d93... --cli-data-dir ... agent host
/proc/5156/exe -> ~/.vscode-server-insiders/code-insiders-8a537d3a1d93... (deleted)
```

It is advertised in the endpoint registry, written the day it started:

```
~/.config/Code - Insiders/agent-host/local-endpoint/entries/951534d3....json
{"schemaVersion":2,"type":"standalone","pid":5156,"protocolVersion":"0.1.0",
"endpoint":{"type":"tcp","host":"127.0.0.1","port":36449},"quality":"insider"}
```

Every new connection reuses it. `classify_agent_host` in `cli/src/tunnels/agent_host.rs` reuses any live registered supervisor by design, and the doc comment says the protocol version is deliberately not checked. So the CLI hands the freshly installed server `--agent-host-bridge-port=36449`, pointing it at a host from a build almost two weeks old.

That old build speaks AHP `1.0.0`, the numbering that was in the tree between aa1d29a95 (Aug 21, "adopt AHP 1.0.0 breaking changes") and 40c9634e1 (Aug 31, "update to AHP 0.9.0"), which renumbered it back down. Because compatibility requires matching majors, `0.9.0` and `1.0.0` have no overlap at all, so negotiation fails outright.

### It cannot recover on its own

The supervisor's update loop is stuck, because it refuses to update while a server child is alive, and one has been alive since Aug 24:

```
~/.vscode-server-insiders/cli/agent-host-insider.log
[2026-09-03 15:57:21] debug Server still running, waiting before updating...
[2026-09-03 16:07:21] debug Server still running, waiting before updating...
```

So the only escape is to know that this process exists and kill it by hand. Nothing in the product tells you that, and the failure is a warning in a log rather than anything visible in the UI.

### Two problems worth separating

1. **The registry lets an arbitrarily old host serve a new client.** This is the same underlying gap as #333175 — entries record schema version, protocol version and quality, but not the build commit, so a host from any older commit of the same quality is reused forever. Recording the commit and refusing to reuse a mismatched one would have prevented this outright.

2. **A failed version negotiation is a dead end for the user.** The client already gets a precise, machine-readable error (`AHP_UNSUPPORTED_PROTOCOL_VERSION`, with the server's supported range). Instead of only logging a warning and leaving the session list empty, that case could surface a real message with a "restart the remote agent host" action, so recovery doesn't require reading logs and running `kill` over SSH.