Fix Streamable HTTP MCP connection leaks

[NickChristensen]

Summary

• Propagate the MCP SDK abort signal into Effect HTTP requests.
• Interrupt response streams when that signal is aborted.
• Add regression coverage for closing an active GET/SSE stream.

Root cause

The custom Effect HTTP-to-Fetch adapter only raced the initial response promise against the request's AbortSignal.

Once response headers had arrived, the adapter returned a ReadableStream that was no longer connected to that signal. Calling client.close() aborted the MCP transport, but the underlying long-lived GET/SSE response continued running and kept its TCP connection open.

For request-scoped MCP clients, this could leave one established connection behind after each invocation and eventually exhaust available file descriptors.

Fix

The adapter now handles cancellation during both phases of a request:

• Before headers, the signal is passed to Effect.runPromise.
• After headers, Stream.interruptWhen connects the response stream to the same signal.

This keeps the existing MCP transport lifecycle unchanged while ensuring local resources are released when the client closes.

Testing

• Added a regression test that opens the Streamable HTTP GET/SSE response, closes the MCP client, and verifies the underlying response body is canceled.
• Package typecheck passed.
• Touched-file lint passed with zero warnings or errors.