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.

Bắt đầu với MCP tool-call path và việc xử lý trạng thái của Settings → MCP servers, sử dụng chính xác lỗi `NativeMcpHostHandle has been destroyed` làm từ khóa tìm kiếm. So sánh các trường hợp reconnect liên quan trong #1662, #1711, #2139 và #505. Được xem là hoàn tất khi một handle đã bị hủy được khôi phục hoặc server được hiển thị là đã ngắt kết nối mà không cần khởi động lại toàn bộ app.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.