muster release v5.16.2

A remote MCPServer recovers its MCP session after its backend is redeployed (#999). A stateful streamable-http backend hands out an Mcp-Session-Id at initialize; a redeployed pod does not know it and answers 404, mcp-go drops the id and from then on every request went out with no session, so every tool call failed (Bad Request: Missing session ID from a Python backend, Invalid session ID from mcp-go) while core_service_status kept reporting connected / healthy, until an operator ran core_service_restart. On gazelle this took every x_pd_* tool away for hours. The client now recognises a lost session – the typed ErrSessionTerminated, or a transport whose session id is gone because the notification listener met the 404 first – re-runs initialize once and retries the call; concurrent callers on the same dead session share one handshake whether it succeeds or fails, a handshake is bounded to the server’s spec.timeout (30 s when unset), one that fails is reported to every caller that waited on it together with the lost-session error (a 401 from the backend still reads as authentication required), and is retried by the next operation, and a client that was closed on purpose never reconnects. Tool calls, listings, resource reads, prompts and the health ping all go through the recovery, for streamable-http servers with and without OAuth; stdio and SSE have no session to lose and are unchanged. Scenario: mcpserver-session-recovery-after-redeploy.