Agent Host WorkIQ MCP remains Running after XAA assertion expires

## Summary

Agent Host WorkIQ MCP servers can remain shown as **Running** and enabled after their enterprise-managed authentication assertion expires. Tool calls then fail with `AADSTS500133`, but the server never transitions to `AuthRequired` and VS Code offers no sign-in action.

All tenant, account, session, request, trace, correlation, and token identifiers have been removed from this report.

## Observed sequence

1. The WorkIQ MCP servers (`workiq-calendar`, `workiq-copilot`, `workiq-mail`, `workiq-me`, and `workiq-teams`) initially reported `needs-auth`.
2. Authentication completed and each server transitioned to `connected (ready)`.
3. Roughly half an hour later, a `workiq-calendar` tool call failed because its assertion had recently expired:

```text
Failed to acquire standard OBO token: AADSTS500133: Assertion is not within its valid time range. Ensure that the access token is not expired before using it for user assertion, or request a new token.
```

4. An immediate retry failed with the same assertion-expiration time, indicating that the stale credential was reused.
5. There was no subsequent `mcp.oauth_required` event and no `needs-auth` status transition.
6. The MCP management UI continued to show every WorkIQ server as enabled and **Running** with a green check mark.

## Expected behavior

Before or when the assertion expires, VS Code should refresh the WorkIQ/XAA credential. If refresh cannot complete silently, the affected MCP server should transition to `AuthRequired` and expose an actionable sign-in control.

At minimum, an authentication failure from an active tool call should not leave the server represented as healthy and ready.

## Likely contributing gaps

### MCP credential expiry is not propagated to the SDK authentication response

The workbench includes `AuthenticationSession.expiresIn` when forwarding authentication to Agent Host:

https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/chat/browser/agentSessions/agentHost/agentHostAuth.ts

However, `CopilotAgentSession.resolveMcpAuthentication` resolves a pending MCP authentication request with only the token:

```ts
{ kind: 'token', accessToken: params.token }
```

https://github.com/microsoft/vscode/blob/main/src/vs/platform/agentHost/node/copilot/copilotAgentSession.ts

This appears to prevent the SDK-side MCP connection from scheduling proactive renewal based on the supplied lifetime. The expiry-aware GitHub credential flow added by #334418 may be useful prior art.

### The WorkIQ failure is a tool result, not an OAuth transport challenge

The expired assertion is returned as an OBO/tool-execution failure while the MCP transport remains connected. Since the SDK does not emit `mcp.oauth_required`, the existing auth-recovery path is never entered and the server's last `Ready` status remains visible.

### XAA reminting uses a short-lived ID token

The current XAA implementation uses the IdP session's `id_token` as the ID-JAG subject when minting a resource token. #330983 proposes preferring the persisted refresh token so reminting can survive ID-token expiry. That PR is still open and has review discussion around fallback behavior and refresh-token preservation.

## UI behavior

The MCP management UI maps `McpServerStatus.Ready` directly to **Running** and only renders its sign-in button for `McpServerStatus.AuthRequired`:

https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/chat/browser/aiCustomization/mcpListWidget.ts

This makes the stale runtime status indistinguishable from a currently usable authenticated server.

## Related

- #330983 — use refresh token for XAA when available
- #316625 — XAA / enterprise-managed authentication tracking
- #321834 — stale MCP OAuth token recovery after 401
- #263990 — MCP authentication token refresh report
- #334418 — expiry-aware Agent Host GitHub credential refresh

## Suggested validation

Add an Agent Host integration test with a deliberately short-lived enterprise-managed MCP credential that verifies:

1. expiry causes proactive refresh or an `AuthRequired` transition;
2. a replacement credential is delivered to every live SDK session;
3. the original tool call can be retried successfully; and
4. the management UI no longer reports `Running` while authentication is unusable.