MCP reconnect leaves active chat with stale client binding

## Short summary

An MCP server can reconnect successfully while an active Copilot chat retains a stale MCP client binding. The tool schemas remain available to the agent, but every execution fails with `No MCP client found for tool ID`.

## Affected version or release

GitHub Copilot app / CLI 1.0.71 on macOS.

## Installation context

Copilot desktop quick chat using the `github-revenue` plugin and its HTTP `revenue-mcp-server`. The failure affected the active chat session. The same server and cached OAuth credentials worked in a fresh resumed process.

## What happened?

On July 17, 2026, the Revenue MCP status showed a successful OAuth reconnect. The active chat then repeatedly completed live-session refreshes while still reporting:

```text
mcp_stale=true
observed_session_mcp=0
target_session_mcp=1 ... 6
```

The tools were visible to the model and one early account lookup succeeded. Subsequent Revenue MCP calls across unrelated tools all failed before reaching the server:

```text
MCP server 'revenue-mcp-server': Error: No MCP client found for tool ID: revenue-mcp-server-get_account_hierarchy
```

The same error occurred for renewal, Salesforce, licensing, changelog, and Kusto tools. This made the failure look like a server outage even though the MCP status and OAuth connection were healthy.

On July 18, after the chat process was resumed fresh, `get_account_hierarchy` succeeded immediately without changing server configuration or authentication.

## Steps to reproduce

1. Open a Copilot quick chat while several third-party MCP servers reconnect from cached OAuth tokens.
2. Observe multiple MCP refresh generation bumps in quick succession.
3. Start using a tool from one of the reconnected servers.
4. Observe that the tool schema is available, but execution can fail with `No MCP client found for tool ID`.
5. Retry other tools from the same server and observe the same client-binding error.
6. Resume or open the workflow in a fresh chat process and observe that the tool succeeds.

This appears timing-dependent. In the captured run, six MCP generation bumps occurred within about one second.

## Expected behavior

After an MCP server reconnects, the active session should atomically refresh to the latest MCP generation before accepting tool calls. A completed refresh should not leave `observed_session_mcp=0` or report success while `mcp_stale=true`.

If the binding cannot be refreshed, the UI and tool router should expose a clear stale-session error and offer to reload the chat rather than reporting the server as unavailable.

## Additional context

Sanitized excerpts from `~/.copilot/logs/github-app.10662.log`:

```text
2026-07-17T17:59:02.898797Z MCP OAuth non-first-party server; cancelling host-token and kicking daemon-owned reconnect ... server_name=revenue-mcp-server

2026-07-17T17:59:03.277754Z third-party MCP server reconnected via cached OAuth tokens server_name=revenue-mcp-server

2026-07-17T17:59:03.277712Z MCP refresh generation bumped ... target_session_mcp=6

2026-07-17T17:59:04.796755Z extensibility live-session refresh completed ... plugins_stale=false mcp_stale=true observed_session_mcp=0 target_session_mcp=6
```

Impact: multi-source workflows fail partway through and can incorrectly tell users that a healthy MCP server is disconnected.

Current workaround: stop retrying in the affected chat, open or resume a fresh chat process, and retry the tool. Restarting the app may be required if fresh chats inherit the stale binding.

Start with the sanitized ~/.copilot/logs/github-app.10662.log excerpts and trace the MCP reconnect and extensibility live-session refresh flow, especially the observed and target session generations. Reproduce several rapid reconnects, then verify that a completed refresh binds the active chat to the current client before tool calls, or exposes a clear stale-session error instead.

Rédigé par le modèle d'indexation à partir du texte de l'issue.