Issue: No Reliable Mapping Between sessionId and streamId for Stateless Resumability

Is your feature request related to a problem? Please describe.
Yes. When building a stateless, multi-pod MCP server using Redis for event storage, the MCP SDK does not provide a way to reliably map the external sessionId (used in HTTP headers and returned to the client) to the internal streamId (used for event storage and replay). The SDK’s event store methods (storeEvent, replayEventsAfter) only receive the streamId, while the onsessioninitialized callback only receives the sessionId. There is no point in the API where both values are available together. This makes it impossible to implement true stateless session resumability across pods or after restarts, since the server cannot look up or reconstruct the correct event stream for a given session.

Describe the solution you'd like
Please provide a way in the SDK to:

• Expose both the sessionId and the corresponding streamId together (e.g., in onsessioninitialized or a new callback).
• Or, guarantee that sessionId === streamId for all sessions.
• Or, provide a mapping utility or hook so stateless resumability can be implemented robustly.

Describe alternatives you've considered

• Attempted to use the session ID as the stream ID by passing it to sessionIdGenerator, but the SDK may still generate its own internal stream ID, breaking this assumption.
• Considered using a global variable or context to temporarily associate the session ID and stream ID during initialization, but this is not safe for concurrent or multi-user environments.
• Currently, the only robust solution is to use in-memory storage, which does not support stateless, cross-pod resumability.

Additional context
Stateless resumability is critical for scalable, production MCP deployments. Without a reliable mapping between session ID and stream ID, it is not possible to resume sessions across pods or after restarts using Redis or any other external event store. This limitation is a blocker for running MCP in a cloud-native, scalable environment.

Inizia tracciando i metodi dell’event store storeEvent e replayEventsAfter insieme al callback onsessioninitialized. Confronta il modo in cui sessionId e streamId vengono creati e passati, quindi definisci un meccanismo di mapping affidabile che funzioni con storage esterno e sessioni concorrenti; il lavoro è completato quando la ripresa funziona tra pod o riavvii senza stato in memoria.