MCP handle destroyed mid-session ("NativeMcpHostHandle has been destroyed") while Settings panel still shows server as Connected

### Short summary

Atlassian (and likely other non-first-party OAuth) MCP server becomes unusable mid-session with `Error: NativeMcpHostHandle has been destroyed` on every tool call, while the Settings → MCP servers panel still reports the server as **Connected** — a false-positive status, the inverse of the false-negative badge behavior described in #1662.

### Affected version or release

GitHub Copilot desktop app, macOS, Apple Silicon (exact build not captured — reporter unsure of precise version at time of failure).

### Installation context

Copilot desktop app, project session using the Atlassian MCP server (`mcp-atlassian-server` / `atlassian-mcp-server`) for Jira ticket creation as part of an automated PR workflow. Multiple other project sessions were open and active in the same app instance at the time.

### What happened?

Every call to any `atlassian-mcp-server-*` tool (e.g. `getAccessibleAtlassianResources`, `atlassianUserInfo`, `createJiraIssue`) failed with:

```
MCP server 'atlassian-mcp-server': Error: NativeMcpHostHandle has been destroyed
```

This was consistent across 10+ retries over an extended period (minutes), with increasing delays between attempts (5s up to 45s+), and persisted even after the user was told by another party that "Atlassian MCP should be back" and re-tried. The failure is scoped to this session — the user reported having other sessions open concurrently and did not report the same failure there, suggesting a per-session/per-process stale handle rather than a global server-side or host-daemon outage.

Critically, the Settings dialog's MCP servers panel shows the Atlassian server as **Connected** throughout — there is no visible indication in the UI that the session's handle to the native MCP host is actually dead. This mirrors the false-status-badge class of bug reported in #1662 (there: red X when actually healthy; here: green/Connected when actually dead).

### Steps to reproduce

1. Configure the Atlassian MCP server (`https://mcp.atlassian.com/v1/mcp` or similar) in a Copilot desktop app session.
2. Use Atlassian MCP tools successfully for a period.
3. At some point (root cause / trigger not yet isolated — possibly related to reconnect/idle/token-refresh handling described in #1662, #1711, #2139), tool calls begin failing with `NativeMcpHostHandle has been destroyed`.
4. Check Settings → MCP servers — the Atlassian server still shows as Connected.
5. Retry the tool call repeatedly, including after waiting — the error persists; there is no in-app affordance to reconnect/reload the handle short of restarting the whole app (see #505, still open, requesting an "update MCP servers" button/command).

### Expected behavior

- The session's MCP client handle should either stay valid for the life of the session, or be transparently recreated/reconnected when the native host handle is destroyed (similar to the "daemon-owned reconnect" logic referenced in #1662's fix).
- If the handle cannot be recovered, the Settings panel status should reflect the real broken state (not show "Connected") so the user isn't misled.
- Ideally, recovery should not require restarting the entire desktop app (all other open project sessions), especially since the failure appears to be scoped to a single session/process. An in-app "reload MCP" action (requested generally in #505) would let a single affected session recover without disrupting others.

### Additional context

- Related issues found while investigating: #1662 (Atlassian/Datadog OAuth status-badge false negative, partially fixed), #1711 (tools don't repopulate into session after daemon reconnect), #2139 (MCP reconnect leaves active chat with stale client binding, `No MCP client found for tool ID`), #505 (feature request for an MCP reload button/command, still open, only workaround today is a full app restart).
- No existing issue was found matching the exact `NativeMcpHostHandle has been destroyed` error string, so filing this as a distinct report in case it's a different failure mode than the ones above, while cross-linking for triage context.
- Workaround used: none available in-session; work was completed without Jira linkage and the ticket-creation step was deferred pending an app restart.

Commencez par le MCP tool-call path et la gestion de l’état de Settings → MCP servers, en utilisant l’erreur exacte `NativeMcpHostHandle has been destroyed` comme terme de recherche. Comparez les cas de reconnexion associés dans #1662, #1711, #2139 et #505. Le travail est terminé lorsqu’un handle détruit est récupéré ou que le serveur est affiché comme déconnecté, sans nécessiter un redémarrage complet de l’application.

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