fix: MCP Streamable HTTP can drop server notifications emitted during a request #8060

Problem

An MCP tool invoked over Streamable HTTP can emit logging or other server notifications, but the notifications are not reliably delivered before the request completes.

The external MCP conformance scenarios tools-call-with-logging and tools-call-with-progress expose this. Against effect@4.0.0-rc.112, the applicable adapter checks fail for the released protocol versions.

Observed behavior

The tool result is returned, but notification frames are missing or the streamed response is not consistently represented as Server-Sent Events.

The HTTP request lifecycle also treats the request-body EOF as though the MCP client disconnected. This can remove the negotiated client/profile state while asynchronous request work is still running.

Expected behavior

Notifications emitted as part of an active HTTP request should be delivered as valid SSE frames before the response stream completes. Finishing the POST request body must not disconnect the logical MCP session.

External regression scenarios

• tools-call-with-logging
• tools-call-with-progress

These checks are applicable protocol behavior and should pass rather than be skipped.

Regression coverage

Add an HTTP adapter test that invokes a tool which emits multiple notifications and then returns a result. Assert that every notification and the final result are observable in order from the streamed response.