fix(transport): cancel in-flight request on streamable-HTTP client disconnect (#857)

[ameyypawar]

Fixes#857.

Problem

On the streamable-HTTP server transport, when a client disconnects while a tool handler is still running, the server-side future is not cancelled — RequestContext::ct never fires. Long-running or destructive tools keep running after the client is gone (Ctrl-C, read timeout, network drop). Only an explicit notifications/cancelled fires the token today.

Scope: stateless mode

This fixes the stateless path (the issue's reproduction). A stateless streamable-HTTP request is one-shot — no session, no resumption — so a dropped response is terminal and safe to cancel.

Stateful (resumable) mode is intentionally left unchanged. There an in-flight SSE stream can be resumed via Last-Event-ID (the transport keeps the request channel alive and advertises retry), so treating a disconnect as a cancellation would break resumption — disconnection is not cancellation for a resumable transport. Cancelling in-flight requests on the resumable path needs a reconnect grace-period design and is out of scope here.

Fix

Give each stateless request its own CancellationToken via serve_directly_with_ct, and cancel it when the client disconnects:

• SSE mode: a CancelOnDisconnect guard on the response stream fires the token if the stream is dropped before it ends naturally. It disarms on natural completion, so a normal response is never cancelled.
• JSON mode: a drop-guard fires the token if the request future is dropped before the handler produces its first message. It disarms once the handler emits anything, so a normal response is never cancelled.

Cancelling the token ends the dedicated serve_directly loop, which cancels the handler's RequestContext::ct.

Notes:

• Detection latency is bounded by when hyper observes the client is gone — prompt on a clean close, and at the next SSE keep-alive for a silent drop.
• Server shutdown now also cancels in-flight stateless SSE handlers rather than leaking them.

Tests

Adds tests/test_streamable_http_disconnect_cancel.rs covering both stateless sub-modes (SSE and JSON). Each test fails without the fix (the handler runs to its timeout) and passes with it. The full non-local test suite passes, and clippy --all-features -D warnings and cargo fmt are clean.

[DaleSeo]

Thanks for the fix, @ameyypawar! I left a couple of comments.

[DaleSeo]

Could we also handle client disconnects after a request-wise SSE stream has been resumed? resume() currently returns a plain ReceiverStream without the disconnect guard.

[DaleSeo]

Could we make sure the disconnect cancellation isn’t silently dropped when the session event channel is full? Since the result of try_send is ignored, a busy session could still leave the handler running until cleanup.

[alexhancock]

@DaleSeo Can you take another look after the revisions? And @ameyypawar It looks like there is a test failure to look into.