Isolate MCP connections per task and surface connection status in the UIs

[yoni-at-strix]

What

Two related changes to how the engine handles connected MCP servers:

1. Resilience. Each MCP connection now runs on its own supervising task, so a
   failure in one connection can no longer cancel the whole scan. On failure a
   connection reconnects once and retries once; if it still fails it is marked
   unavailable and the run continues without it.
2. Visibility. The terminal UI and the web viewer now show a run's MCP
   connections and their live status (healthy, in use, offline).

Why

An MCP connection's live session used to be opened on the run's main task, and the
streamable-HTTP transport keeps an internal task group open on that task for the
session's lifetime. A background error from a provider (for example an HTTP 403 on
a background request) cancelled that task group's scope, which cancelled the entire
scan and surfaced as a bare CancelledError. There was also no way to see which
MCP servers a run had connected or whether they were still alive.

What changed

• Each connection is owned by a dedicated task (SupervisedMcpSession) that
  connects, holds, and cleans up the session on one task. Callers reach it over a
  queue and get a value back, so a session failure surfaces as a failed tool result
  rather than a cancellation. On a failure the supervisor reconnects once and
  retries once (reusing the existing connect path); a connection that dies while
  idle also gets one reconnect. If reconnect fails, the connection is marked dead
  for the run and later calls return a clean "unavailable" result. This also fixes
  the teardown "exit cancel scope in a different task" errors, since connect and
  cleanup now run on the same task.
• The engine exposes a per-run connection roster with each connection's status
  (name, provider, tool count, dead) and persists it to the run record, so both
  live and finished views can render it. Only these non-secret fields are exposed.
• Terminal UI: a scrollable "MCP Connections (N)" sidebar panel with per-
  connection status; list_mcps also reflects offline connections.
• Web viewer: a matching sidebar panel fed from the persisted roster, with
  "in use" derived from tool-call events.

Testing

New unit tests cover containment, reconnect-then-retry, give-up-and-mark-dead, the
idle-death self-heal, roster persistence, and that connection config and tokens
never reach logs, reprs, or disk. The full Python suite, Go build/vet/test, ruff,
mypy, and the viewer frontend typecheck and build all pass.

[greptile-apps]

Greptile Summary

The PR isolates MCP connections behind per-connection supervisor tasks and exposes persisted connection health in the terminal and web interfaces.

• Bounds teardown of active MCP calls by cancelling the supervisor after the graceful-shutdown timeout.
• Handles cancelled startup readiness without skipping supervisor cleanup.
• Adds reconnect behavior, connection status persistence, and MCP status panels to both UIs.

Confidence Score: 5/5

The PR appears safe to merge because both previously reported MCP teardown failures are addressed and no blocking failure remains.

No blocking failure remains.

Important Files Changed

Filename	Overview
strix/tools/mcp/session.py	Introduces task-owned MCP sessions and now addresses both previously reported teardown defects through cancellation-safe readiness handling and bounded active-call shutdown.
strix/core/runner.py	Integrates supervised MCP lifecycle cleanup and publishes non-secret connection-status snapshots.
strix/tools/mcp/agent_tools.py	Routes agent MCP operations through the new registry and supervised-session abstraction.
strix/interface/tui/internal/app/view.go	Adds the terminal MCP connection panel, status rendering, and roster scrolling.
strix/interface/viewer/frontend/src/components/Sidebar.tsx	Adds the viewer MCP roster with healthy, active, and offline states.

_{Reviews (2): Last reviewed commit: "Bound MCP session teardown and handle a ..." | Re-trigger Greptile}

[yoni-at-strix]

@greptile