Surface MCP authentication problems persistently in the primary UI

## Summary

MCP authentication problems are effectively hidden until after I send a request that needs the affected server.

The primary **Customizations** UI shows counts for Plugins, MCP Servers, Skills, and other customization types, but gives no persistent indication that one or more MCP servers need authentication or are otherwise unavailable.

## Actual behavior

1. An MCP server's credentials expire or otherwise require authentication.
2. Open the Agents window and its **Customizations** UI.
3. There is no visible warning or unhealthy-server count on **Overview** or **MCP Servers**.
4. Send a request that depends on the affected server.
5. Only after sending, a short-lived authentication affordance appears for a few seconds. It is easy to miss or not complete in time.
6. The agent continues without that source/tool. Only later in the response does the capability gap become apparent, for example:

> **Source gap:** The Slack connector was unavailable, so I could not verify or cite the supporting Slack discussion.

At that point the request has already run and produced an incomplete answer.

## Expected behavior

MCP authentication and connection health should be visible persistently before a request is sent, with a durable recovery action. For example:

- Show an error/warning badge or unhealthy count on the **MCP Servers** row in Customizations.
- Show affected servers and their status on the Customizations Overview.
- Keep the warning visible until authentication succeeds or the server is disabled.
- Provide a reliable **Authenticate** / **Reconnect** action from that status.
- Consider a pre-send warning when the request/session expects tools from an unavailable MCP server, rather than silently continuing with reduced capabilities.

The important part is that this is not only a transient notification after submission. Authentication trouble should be discoverable from the primary UI at any time.

## Impact

- Users do not know an MCP-backed source is unavailable before asking a question.
- Requests run with silently reduced capabilities and return partial answers.
- The recovery window is brief and appears at the wrong time: after the user has already committed the request.
- This makes source-backed answers harder to trust because the missing capability is disclosed only later in the response.

## Related issues

- #327640 — Agent Sessions authentication action is a no-op and the flow has no feedback.
- #330837 — credential failures can remove MCP tools with no surfaced error or reset path.
- #334271 — interactive MCP activation failures leave tools absent with no surfaced error.

The existing reports cover broken authentication and silent tool loss. This issue is specifically about a persistent, proactive health signal and recovery entry point in the primary UI.