fix: MCP Streamable HTTP loses reverse-request correlation across POST requests

[lloydrichards]

Problem

Server-to-client MCP requests started while handling one Streamable HTTP POST cannot reliably consume the client response when that response arrives in a later POST.

The external MCP conformance scenarios time out against effect@4.0.0-rc.112:

• tools-call-sampling
• tools-call-elicitation

Observed behavior

The server sends the sampling or elicitation request, but the response is routed using the transient HTTP request client ID instead of the client/profile that originated the reverse request. The original tool call remains waiting and eventually times out.

Expected behavior

A reverse request ID should remain correlated with its originating logical MCP client and negotiated profile across HTTP requests. A matching client response should resume the pending tool invocation.

Affected behavior

This is not July-only behavior. Sampling and elicitation are applicable to their respective released protocol versions, so these failures should not be represented as protocol skips.

Regression coverage

Add an HTTP adapter test that:

1. starts a tool call;
2. receives a server sampling or elicitation request;
3. returns the reverse-request response through a separate POST;
4. observes the original tool result complete without timing out.

[lloydrichards]

see #8060 (comment)