Send DELETE request when closing a Streamable HTTP session on the client

[halter73]

This updates StreamableHttpClientSessionTransport.DisposeAsyncto send a delete request.

5. Clients that no longer need a particular session (e.g., because the user is leaving the client application) SHOULD send an HTTP DELETE to the MCP endpoint with the Mcp-Session-Id header, to explicitly terminate the session.

• The server MAY respond to this request with HTTP 405 Method Not Allowed, indicating that the server does not allow clients to terminate sessions.

https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http

[halter73]

Reminder to self to include _mcpProtocolVersion here once #500 is merged.

[stephentoub]

If this fails, it looks like that failure will propagate (for things other than cancellation). Do we want to eat any failures?

[stephentoub]

Could also be:

Suggested change

	using var deleteResponse = await _httpClient.SendAsync(deleteRequest, CancellationToken.None).ConfigureAwait(false);
	(await _httpClient.SendAsync(deleteRequest, CancellationToken.None).ConfigureAwait(false)).Dispose();

[halter73]

I'm on the fence about this. Would it be even better to make this fire-and-forget? We risk disposing the SocketsHttpHandler before the DELETE request completes, but maybe that's better than unnecessarily slowing down DisposeAsync.

In general, I do not like catching exceptions unless there is a clear reason we should. I've seen too many cases where overly broad catch blocks in teardown logic make it harder to diagnose errors related to graceful shutdown.

The flip side of this is that we might be disposing the client in reaction to some other sever-side error, and an error from the DELETE request could obscure that. And most people probably don't really care if the DELETE request succeeds or even that it gets sent.