**Describe the bug** With protocol version `2026-07-28` over Streamable HTTP, `RequestHandle::cancel()` can hang while the original request POST is waiting for its first response event. The client worker awaits `post_message_with_max_sse_event_size(...)` inline. While that future is pending, the worker cannot process the cancellation message that should close the request's HTTP/SSE response path. A long-running tool that emits no events therefore cannot be cancelled through RMCP's public client API. This reproduces on current `main` (`6f8dcde`, `rmcp` 3.1.3). **To Reproduce** 1. Start a stateless Streamable HTTP server using protocol version `2026-07-28`. 2. Make its `tools/call` handler wait for `RequestContext::ct` without returning a response or progress event. 3. Connect with `StreamableHttpClientTransport` and `ClientLifecycleMode::Discover`. 4. Start the call with `send_cancellable_request(...)`. 5. After the handler starts, call `RequestHandle::cancel(...)` inside a five-second timeout. The cancel call times out: ```text RequestHandle::cancel should not wait for the response stream: Elapsed(()) ``` The regression test in the proposed PR exercises this exact flow using RMCP on both sides. **Expected behavior** `RequestHandle::cancel()` should return promptly. RMCP should abort the pending request POST, closing that request's response path so the server cancels the handler and fires `RequestContext::ct`. This is the required behavior for the modern protocol: - [MCP 2026-07-28 transport overview](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports#cancellation): Streamable HTTP cancellation closes the request's response stream. - [MCP 2026-07-28 Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http#cancellation): the server must treat that close as cancellation and stop work as soon as practical. **Logs** No transport error is logged. The cancellation future remains pending until the test timeout. **Additional context** The modern client path already converts a cancellation message into cancellation of a per-request `CancellationToken`, so this appears to be an ordering bug rather than an intentional limitation. The token is currently registered only after the POST produces an SSE response, which is too late to cancel a POST still waiting for its first response event. Issues #857 and PR #967 fixed the matching server-side disconnect handling. This issue is the client-side path needed to trigger that behavior through `RequestHandle::cancel()`.