Custom connector silently hangs indefinitely (no error, no timeout) after long-idle session — zero inbound traffic at server, related to #469

**Related to:** #469 (connector wrapper layer reliability), #227 (zero inbound traffic, closed not-planned)

## Summary

After leaving a claude.ai session with an active custom MCP connector idle overnight
(~14+ hours), the first tool call made against it hung indefinitely — no error, no
progress indicator resolving, nothing — until manually stopped after several minutes.
Asking Claude "is the connection working?" produced a confident but unverified false
positive ("the connection is working fine... likely just tool schema loading"), based
on no actual tool call. A second, simpler query was attempted and hung for a full 12
minutes before being manually stopped. Disconnecting and reconnecting the connector
(Settings → Connectors) immediately resolved it — all subsequent queries worked
normally.

## Why this looks like the same root cause as #469, with a different symptom shape

#469 describes ~10-30% of calls failing fast (retry succeeds "within seconds") with
swallowed error messages. This report describes a *complete* hang with *no* error at
all, lasting 10+ minutes, specifically triggered by a long idle period. Same
underlying signature — zero inbound traffic at the MCP server during the failure — but
a different trigger (idle duration) and a much worse outcome (total silence instead of
a fast, swallowed failure).

## Server-side evidence (ruling out our own infrastructure)

We operate the MCP server involved and pulled Azure Container Apps logs to rule out
server-side causes before concluding this is connector-side:

- Request/response counts matched ~1:1 in every 15-minute bucket across the full prior
20 hours, including overnight — the server was continuously healthy and responsive
to everything it received.
- The container app's single replica had been continuously active for 3+ days with no
restart, deploy, or scaling event in the relevant window.
- No log line of any kind — request, OAuth, or audit — was found matching this user's
identity anywhere near the time of either hang. The request never reached us.

This rules out a slow query, a database timeout, a stuck connection pool, and a
replica restart as explanations. The failure is upstream of our server entirely.

## Impact

- No error surfaced to the user or the model at any point during either hang — the
only recourse was manually stopping generation and guessing that a reconnect was
needed, then confirming that guess empirically.
- The model, asked directly whether the connection was healthy, gave a confident wrong
answer rather than either testing it or declining to guess.
- No `ofid_` reference ID was shown for either hang (unlike a connection-establishment
failure) — reconnecting was the only diagnostic tool available to the end user.

## Ask

Per the MCP spec's own guidance (implementations SHOULD establish timeouts for all
sent requests and SHOULD issue `notifications/cancelled` and stop waiting when a
timeout is hit — https://modelcontextprotocol.io/specification/2025-06-18/basic/utilities/cancellation),
apply a bounded client-side timeout to outbound tool-call requests from the claude.ai
connector wrapper, distinct from whatever is currently allowing this to hang
indefinitely. When it fires, surface a clear, actionable error to the user (e.g. "the
connector did not respond — try reconnecting") instead of an indefinite spinner with
no signal.

## Environment

- claude.ai web (Enterprise), custom OAuth-authenticated MCP connector
- Server: our own Container Apps-hosted MCP server, PureHavenDW tool
- Date of occurrence: 2026-08-20 (overnight idle from 2026-08-19)