feat: transparent session re-init on HTTP 404 for streamable HTTP

[DaleSeo]

Fixes #733

Motivation and Context

The MCP spec on Session Management states that when a client gets an HTTP 404 response to a request with Mcp-Session-Id, it must start a new session by sending a fresh InitializeRequest without a session ID. Before, the streamable HTTP client would show a generic UnexpectedServerResponse error and get stuck with the old session, which goes against the spec.

This PR allows the client to detect 404 responses on session-aware requests and show them as a new SessionExpired error. It will then automatically re-initialize by replaying the original initialize handshake, setting up a new SSE stream, and retrying the original message, all without the caller noticing. It will attempt a single retry, and if the re-initialization fails, the error will propagate normally to avoid infinite loops.

How Has This Been Tested?

Added new integration tests to verify both the low-level error detection and the end-to-end transparent recovery.

Breaking Changes

StreamableHttpError gains a new SessionExpired variant. Because the enum is #[non_exhaustive], downstream code that matches on it will not break.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

In general, to fix cleartext logging of sensitive information, you either (a) remove the sensitive data from the log output entirely, or (b) mask/replace it with a redacted or hashed version that cannot be used to compromise security. You only log high‑level status (e.g., “session reinitialized”) rather than the exact session identifier or token.

For this specific code, the data in question is new_session_id_str / new_session_id, which likely contains a session identifier. The safe approach is to ensure that, when we log reinitialization, we do not ever include the actual session id. Since the only logging machinery visible in this file is tracing::debug, and CodeQL says that the mapping operation leads to a logging sink, the least‑intrusive fix is to add a dedicated debug message that explicitly avoids printing the session id, and not log new_session_id_str directly at all. To make the intent clear and to satisfy the analyzer, we can log only whether a session id was obtained (e.g., Some vs None), without including its content. This preserves existing functionality (session handling logic is unchanged) while removing any potential for accidentally logging the raw session identifier.

Concretely, within perform_reinitialization in crates/rmcp/src/transport/streamable_http_client.rs, right after we convert new_session_id_str into new_session_id, we’ll add a debug! call that reports only the presence/absence of the ID, not the ID value. We do not need any new imports (the file already imports tracing::debug). We avoid any change to how new_session_id is used elsewhere.