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.

從經過清理的 ~/.copilot/logs/github-app.10662.log 摘錄開始，追蹤 MCP 重新連線和 extensibility live-session 重新整理流程，尤其關注已觀察到的工作階段世代和目標工作階段世代。重現多次快速重新連線，然後驗證已完成的重新整理是否會在工具呼叫之前將使用中的聊天繫結至目前的用戶端，或者改為揭露明確的 stale-session 錯誤。

由索引模型根據 Issue 內容生成。