Handle streamable POSTs to properly support new streamable transport protocol spec

[stallent]

The streamable http transport spec handles SSE a bit different than the original sse transport spec. In the original spec, POSTs returned their responses as sse messages on the GET stream. Now the POSTs themselves can sse streams so the GET becomes primarily for notifications (or resuming a POST that experienced a broken connection, but thats a separate can of worms that has not been properly addressed yet).

Motivation and Context

The current HTTPClientTransport does not support streams coming back from POSTs and it must to work with latest spec servers.

How Has This Been Tested?

We have 3 sandbox servers set up with latest server sdk from anthropic. Each configured differently to exercise expected variations.

// streaming response + session management
https://hgai-sandbox.aks.stage.mercury.io/streamable/mcp

// JSON response + session management
https://hgai-sandbox.aks.stage.mercury.io/streamable/json/mcp

// JSON response with no session management
https://hgai-sandbox.aks.stage.mercury.io/streamable/stateless/mcp

Breaking Changes

none

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

Supporting true resumability will require some additional work that was beyond the scope of this initial PR

[stallent]

@mattt trying to follow from my phone while offline today so may have missed it, but while you are in there I believe we are suppose to wait until after we are initialized before starting up the GET. Wasn’t a clean way to do that since the transport itself isn’t aware. If you haven’t done that and can think of a good way, that would let us avoid the error on initial GET (that works on retry because it then has the session id)