Docker stdio MCP servers duplicated on /new and /resume (v1.0.68)

## Summary

On **v1.0.68**, running `/new` or `/resume` (resuming a session not started during the current CLI run) spawns a **fresh set of stdio MCP `docker run` clients without tearing down the previous set**. Duplicates accumulate within the **same** CLI process for its entire lifetime.

This looks related to #3440 but is a **different code path**: #3440 was about `session.disconnect()` not killing stdio processes (fixed in 1.0.51). Here, **no disconnect happens at all** — the CLI re-initializes MCP servers on `/new`/`/resume` and spawns a new set while the old set stays connected, so the kill-on-disconnect logic never runs.

## Environment

- Copilot CLI **1.0.68**
- macOS (Darwin arm64)
- MCP servers configured as stdio Docker containers (`docker run -i --rm …`) in `~/.copilot/mcp-config.json` — one `github-mcp-server` + three `grafana` instances

## Actual behavior

Every configured stdio MCP server is duplicated per `/new` or `/resume`. `docker ps` shows 2× (or more) of every server, all parented to the same live `copilot` process. Because the containers run with `--rm`, they only self-remove when the whole CLI exits — so they pile up for the entire CLI session.

## Affected version

1.0.68

## Steps to reproduce the behavior

1. Configure one or more stdio Docker-based MCP servers.
2. Start the CLI (session A) → one set of `docker run` clients spawns.
3. Run `/new`, **or** `/resume` a session that was **not** opened during the current CLI run.
4. A second set of clients spawns; the first set is **not** disconnected.

## Expected behavior

On `/new` or `/resume`, the CLI should either **reuse** the existing MCP server connections or **disconnect** the outgoing session's stdio MCP servers before starting new ones.

## Additional context

### Evidence

Single `copilot` PID `71692`, alive ~19 min, holding **two full sets** spawned ~2 min apart — none orphaned, all share that PID as parent:

```console
$ ps -eo pid,ppid,etime,command | grep '[d]ocker run'
72222 71692 19:12 docker run -i --rm --network host … github-mcp-server
72225 71692 19:11 docker run -i --rm … grafana/mcp-grafana -t stdio
72226 71692 19:11 docker run -i --rm … grafana/mcp-grafana -t stdio
72227 71692 19:11 docker run -i --rm … grafana/mcp-grafana -t stdio
72869 71692 17:32 docker run -i --rm --network host … github-mcp-server
72870 71692 17:31 docker run -i --rm … grafana/mcp-grafana -t stdio
72871 71692 17:31 docker run -i --rm … grafana/mcp-grafana -t stdio
72880 71692 17:30 docker run -i --rm … grafana/mcp-grafana -t stdio

$ docker ps --format '{{.Image}}' | sort | uniq -c
6 grafana/mcp-grafana
2 nexus…/github/github-mcp-server
```

### Impact

Resource leak: duplicated containers consume memory/CPU and, for named containers, cause `container "x" already exists` errors on the next spawn. The only reliable cleanup today is fully exiting the CLI.

### Related

- #3440 (fixed the disconnect path in 1.0.51; this is the `/new` + `/resume` re-init path, still leaking on 1.0.68)

Start by tracing the MCP initialization paths triggered by `/new` and `/resume`, using the `~/.copilot/mcp-config.json` setup and the Docker reproduction steps. Done means switching sessions either reuses the existing stdio clients or disconnects the outgoing session so `docker ps` shows only one set of MCP containers during the CLI run.

Written by the indexing model from the issue text.