Feature: MCP Connection Health Center with OAuth Renewal, Capability Drift, and Tool Diagnostics

## Summary

Add an MCP Connection Health Center that continuously helps users inspect connector status, OAuth/token freshness, advertised tool capabilities, permission implications, and failure diagnostics across configured MCP servers.

## Problem / Opportunity

Forge already includes MCP registry, client, HTTP transport, OAuth support, CLI commands, dashboard endpoints, and permission handling for MCP/network tool use. As users add more connectors, they need an operational workflow for understanding whether an MCP connection is healthy and safe to use:

- Is the server reachable right now?
- Is OAuth expired, close to expiring, or refreshable?
- Did the server's tool list change since the last successful connection?
- Which tools imply network, file, shell, or credential-sensitive permissions?
- Why did a connector fail: auth, transport, schema, timeout, or permission policy?
- Which tasks recently used this connector?

A health center would make MCP integrations easier to operate without weakening Forge's permission model.

## Proposed Feature

Build MCP health and diagnostics across CLI and dashboard:

- `forge mcp doctor` for all connections and `forge mcp doctor CONNECTION_ID` for one connection.
- Health records for reachability, auth state, token expiry/refresh, transport errors, protocol/schema compatibility, and discovered tools.
- Capability drift detection when an MCP server adds, removes, or changes tools.
- Permission impact summary for each discovered tool namespace.
- Dashboard view for connection status, recent failures, OAuth renewal actions, and capability diffs.
- Redacted diagnostic export suitable for support or issue reports.

## Scope

Expected implementation areas:

- `src/mcp/registry.ts`, `src/mcp/client.ts`, `src/mcp/http-transport.ts`, and `src/mcp/oauth.ts`.
- `src/cli/commands/mcp.ts` for doctor, refresh, capability diff, and diagnostic export commands.
- `src/permissions/risk.ts` and `src/permissions/manager.ts` for permission impact summaries without bypassing runtime prompts.
- `src/persistence/index-db.ts` for storing last-known health and capability snapshots.
- `src/ui/server.ts` and `src/ui/public/` for dashboard connection health views.
- `src/security/redact.ts` for safe diagnostics.
- Docs in `docs/CLI-REFERENCE.md`, `docs/SETUP.md`, and architecture/security sections.

## Acceptance Criteria

- [ ] `forge mcp doctor` reports health for every configured connection with reachability, auth, transport, and tool-discovery status.
- [ ] OAuth-backed connections show token freshness and provide a safe renewal flow without printing secrets.
- [ ] Forge stores last-known MCP tool capability snapshots and can show added, removed, or changed tools.
- [ ] Capability summaries identify likely permission classes and namespaces, while actual tool invocation still goes through `requestPermission`.
- [ ] Dashboard users can inspect MCP health, recent failures, and capability drift without editing config files manually.
- [ ] Diagnostic exports redact tokens, headers, endpoint secrets, and credential-like values.
- [ ] Tests mock MCP servers/transports and cover auth failures, refresh behavior, drift detection, redaction, and timeout reporting.
- [ ] Documentation includes troubleshooting guidance for OAuth, local stdio servers, HTTP servers, and permission denials.

## Non-Goals

- Automatically trusting new MCP tools after capability drift.
- Storing raw OAuth secrets outside the existing credential/keychain model.
- Replacing the existing MCP add/remove/auth commands.
- Requiring background polling for every connection in the first version.

## Dependencies / Risks

- Health checks should avoid long timeouts and should not slow down normal CLI startup.
- Capability drift must be treated as a review signal, not as an automatic allow/deny decision by itself.
- OAuth refresh flows need careful redaction and platform-specific credential handling.
- Tests must not depend on live MCP servers or external network calls.

## Open Questions

- Should MCP health checks run only on demand, or also periodically through the daemon?
- Should capability drift require user acknowledgement before a changed tool can run?
- Should health records be retained globally or per project?
- Should MCP diagnostics integrate with the broader task trace/replay feature?