Fix sse-retry hang: cancel foreground transport send when response arrives via background channel

The sse-retry conformance test hangs intermittently because of a race between
the background GET SSE stream and the tools/call POST request at the conformance
server. When the background GET arrives at the server AFTER the tools/call POST
(due to CI scheduling delays), the server sends the tool response on the
background GET stream instead of the foreground retry GET. The foreground retry
GET then blocks forever waiting for data that never comes.

This happens because the server's handleGetSSEStream checks pendingToolCallId
and sends the tool response to whichever GET request is being handled at that
moment. If background GET #1 is delayed and arrives after tools/call sets
pendingToolCallId, it receives the response. The foreground retry GET #2 then
arrives and finds pendingToolCallId=null, so it gets no response.

Fix by creating a linked CancellationTokenSource in SendRequestAsync that
cancels when the response TCS is completed (from any channel). This interrupts
the blocked foreground transport send, allowing SendRequestAsync to proceed
to the TCS await where the response is already available.

The disposal timeout in transport DisposeAsync is kept as defense-in-depth
for cases where the background GET stream doesn't respond promptly to
cancellation during shutdown.

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Author: Copilot

src/ModelContextProtocol.Core/McpSessionHandler.cs

@@ -528,7 +528,32 @@ public async Task<JsonRpcResponse> SendRequestAsync(JsonRpcRequest request, Canc
                 LogSendingRequest(EndpointName, request.Method);
             }
 
-            await SendToRelatedTransportAsync(request, cancellationToken).ConfigureAwait(false);
+            // Cancel the transport send when the response TCS completes. This handles the case
+            // where a concurrent background stream (e.g., Streamable HTTP's background GET SSE)
+            // already delivered the response to the session via the shared message channel,
+            // while the foreground transport send (a retry GET that the server left open without
+            // sending a response) is still blocked waiting for data. Without this, the foreground
+            // await at SendToRelatedTransportAsync would hang indefinitely.
+            using var sendCts = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken);
+            _ = tcs.Task.ContinueWith(
+                static (_, state) =>
+                {
+                    try { ((CancellationTokenSource)state!).Cancel(); }
+                    catch (ObjectDisposedException) { }
+                },
+                sendCts,
+                CancellationToken.None,
+                TaskContinuationOptions.ExecuteSynchronously,
+                TaskScheduler.Default);
+
+            try
+            {
+                await SendToRelatedTransportAsync(request, sendCts.Token).ConfigureAwait(false);
+            }
+            catch (OperationCanceledException) when (!cancellationToken.IsCancellationRequested)
+            {
+                // The send was canceled because the response arrived through another channel.
+            }
 
             // Now that the request has been sent, register for cancellation. If we registered before,
             // a cancellation request could arrive before the server knew about that request ID, in which