[BUG] MCP Streamable HTTP client still does not re-initialize after HTTP 404 session-not-found on v2.1.109 (regression from claimed fix in v2.1.41)

Spec reference: Streamable HTTP §session management clause 4 — "When a client receives HTTP 404 in response to a request containing an \Mcp-Session-Id\, it MUST start a new session by sending a new \InitializeRequest\ without a session ID attached."

Claude Code version: v2.1.109
MCP server: Jexida MCP, Streamable HTTP transport (Python SDK, official \StreamableHTTPServerTransport\). Code is spec-compliant — returns HTTP 404 + body \{"error": "Session not found"}\ when session_id is not in registry (server impl).

Repro:

1. Connect Claude Code to a Streamable HTTP MCP server. Session established, tools available.
2. Restart the MCP server process (or trigger a redeploy that restarts the service). Server loses in-memory session map.
3. From Claude Code, invoke any MCP tool.

Expected (per spec): Client receives 404 → drops stale session_id → POSTs fresh \InitializeRequest\ with no session_id → server creates new session → tool call retries → succeeds, transparently to the user.

Actual: Client surfaces \Streamable HTTP error: Error POSTing to endpoint: {"error": "Session not found"}\. No retry. Subsequent tool calls all fail with the same error. Only \/mcp Reconnect\ recovers.

Impact in our environment: A multi-hour MCP-server rollout session today required 4 manual \/mcp Reconnect\s — each one breaks flow and forces a full context reload. The supposed fix in v2.1.41 (per #9608 comment) is not present in v2.1.109, OR was a partial fix that doesn't cover this exact case.

Cross-reference: #9608 (closed, claimed fixed v2.1.41), #27142 (closed-inactive), #17412, #30224, #36308, #10129 — all reporting same shape.