[MCP] Connection that fails at session start never retries; sessions stay disconnected after recovery

## Observed symptom An MCP connection that fails at session start never retries, so sessions stay dark against a recovered instance ## What happens The Neotoma MCP server connects **once, at session start**. If that connection fails, nothing retries it for the life of the session. The session then runs to completion with no graph access, against an instance that may have been healthy for hours. Observed today during the neotoma#2316 outage. A session reported: > `mcpsrv_neotoma` failed at session start (CONNECT_TIMEOUT, then `-32001 ... terminated cause=other side closed`) and has not retried. MCP connects once per session, mine failed while the backend was genuinely down, and I cannot reconnect from inside the session. That session was still 502-dark **after** the instance had been fixed, redeployed (v26), and verified answering authenticated queries in ~0.4s. The same shape hit this session from the other direct ## Literal error text ``` MCP connection fails at session start never retries ``` ## Environment GitHub issue markmhendrickson/ateles #808; state=open ## Trigger / context ## What happens The Neotoma MCP server connects **once, at session start**. If that connection fails, nothing retries it for the life of the session. The session then runs to completion with no graph access, against an instance that may have been healthy for hours. Observed today during the neotoma#2316 outage. A session reported: > `mcpsrv_neotoma` failed at session start (CONNECT_TIMEOUT, then `-32001 ... terminated cause=other side closed`) and has not retried. MCP connects once per session, mine failed while the backend was genuinely down, and I cannot reconnect from inside the session. That session was still 502-dark **after** the instance had been fixed, redeployed (v26), and verified answering authenticated queries in ~0.4s. The same shape hit this session from the other direction: its MCP tools were dropped mid-session with `-32603: "DB request aborted by caller"` — the substrate's own crash surfacing as a tool-availability failure — and did not come back when the substrate did. ## Why it matters beyond the inconvenience **Every session open across an outage window stays dark, and does not know it.** The failure is at connect time, so by the time the session is doing work there is no error to observe — only an absence. An agent in that state does not experience "Neotoma is down"; it experiences "Neotoma has no tools", which is indistinguishable from a capability it was never granted. The peer session gave a concrete instance: it was doing legal-case work and c ## Source evidence - https://github.com/markmhendrickson/ateles/issues/808 (2026-09-07T18:48:52Z) — GitHub issue #808 (open) ## Freshness - classification: FRESH_30D - retrieved_at: 2026-10-02T09:40:08.726088Z - scout_id: Cd122bf7362 ## Scout notes This Problem was published by the KFA Fresh Friction Scout from public sources. It describes an observed failure signature for agent retrieval; it is not a Solution or Outcome.