feat(client): add explicit session_id support for Streamable HTTP resumption

[mrutunjay-kinagi]

Summary

Adds first-class support for reusing a previously issued mcp-session-id on the Python client side.

Note: this follows the same high-level design as the C# implementation for session resumption in modelcontextprotocol/csharp-sdk (#946, implemented by #1029):

• transport-level known session IDs
• explicit client resume flow that skips initialize
• caller control over session ownership/termination behavior

Closes #2116

Changes

• streamable_http_client(...) accepts session_id: str | None and seeds transport state with it.
• StreamableHTTPTransport accepts optional initial session_id.
• URL Client now supports:
  • streamable_http_session_id
  • streamable_http_terminate_on_close
  • streamable_http_initialize_result
• Added Client.resume_session(...) explicit resume constructor.
• Added ClientSession.resume(...) to apply previously negotiated initialization data and skip the initialize handshake.
• streamable_http_client(...) now starts GET stream immediately when resuming with a known session ID.
• StreamableHttpParameters supports session_id and forwards it in ClientSessionGroup.

Validation

• .venv/bin/pytest -q tests/client/test_client.py -k "streamable_http or resume_session or requires_session_id"
• .venv/bin/pytest -q tests/client/test_session_group.py -k "establish_session_parameterized"
• .venv/bin/pytest -q tests/shared/test_streamable_http.py -k "seeded_session_id_header"

[mrutunjay-kinagi]

Follow-up on latest CI for commit dbddc8b:

• Workflow run succeeded: https://github.com/modelcontextprotocol/python-sdk/actions/runs/23387443373\n- Required gate all-green passed.
• Four 3.11 matrix jobs are shown as failed individually, but these are non-blocking in this workflow configuration and are aggregated by all-green.

[mrutunjay-kinagi]

@maxisbey Can you please take a look at this?

[awest25]

Hey @maxisbey / @mrutunjay-kinagi, I’m following this closely because session resumption would simplify my current agent orchestration setup.

Right now, the initialization handshake overhead on every restart is a bottleneck for my automated agents hooking into this. This PR gets us closer to parity with the C# SDK’s session handling, which is huge for stateful workflows.

I noticed it’s currently hit some conflicts. I’m happy to pull this branch locally and help with the rebase if that would move this into the v2 milestone faster. Is session resumption definitely staying on the roadmap for the v2 architecture?

[mrutunjay-kinagi]

Hey @maxisbey / @mrutunjay-kinagi, I’m following this closely because session resumption would simplify my current agent orchestration setup.

Right now, the initialization handshake overhead on every restart is a bottleneck for my automated agents hooking into this. This PR gets us closer to parity with the C# SDK’s session handling, which is huge for stateful workflows.

I noticed it’s currently hit some conflicts. I’m happy to pull this branch locally and help with the rebase if that would move this into the v2 milestone faster. Is session resumption definitely staying on the roadmap for the v2 architecture?

I've resolved the conflict.