Add client completion notification and details

[stephentoub]

Introduce a new mechanism for reporting MCP client session completion details, including both graceful and error terminations. Add a Completion property to McpClient, exposing a Task<ClientCompletionDetails> that completes with details about session closure. Implement extensible completion details (including StdioClientCompletionDetails for stdio transports) and propagate them via a new internal TransportClosedException.

Closes #1332
Closes #438

[halter73]

I would like to see this implemented for stateful Streamable HTTP when there are 404s as well, but I think this is already a nice improvement even without that part. I have a small preference for the abstract Completion property over the method, but I don't care too much either way on that.

[halter73]

It turns out 10x wasn't enough 😭

 Failed Checks:
  - ClientRespectsRetryField: Client MUST respect the retry field, waiting the given number of milliseconds before attempting to reconnect
    Error: Client reconnected very late (5355ms instead of 500ms). Client appears to be ignoring the retry field and using its own backoff strategy.

https://github.com/modelcontextprotocol/csharp-sdk/actions/runs/22415043174/job/64898373590?pr=1368

[halter73]

@copilot Can you please remove the HttpStatusCode parameter from SetSessionExpired and replace this line with just HttpStatusCode = HttpStatusCode.NotFound? That's only assuming that this is only called given a 404 status code which appears to be that case.

[halter73]

@copilot Assuming that the ?? new TransportClosedException(new HttpClientCompletionDetails() logic should be unreachable, can use configure the HttpClientCompletionDetails with an exception stating as much? If not, can you configure the HttpClientCompletionDetails with an exception describing how the client might have disconnected?

[stephentoub]

It turns out 10x wasn't enough 😭

 Failed Checks:
  - ClientRespectsRetryField: Client MUST respect the retry field, waiting the given number of milliseconds before attempting to reconnect
    Error: Client reconnected very late (5355ms instead of 500ms). Client appears to be ignoring the retry field and using its own backoff strategy.

https://github.com/modelcontextprotocol/csharp-sdk/actions/runs/22415043174/job/64898373590?pr=1368

I think there's a real pre-existing bug lurking.

[halter73]

This appears to be failing the API check due to adding an abstract member even though the McpClient constructor is experimental.

Error: /Users/runner/.dotnet/sdk/10.0.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.ApiCompat.ValidatePackage.targets(39,5): error CP0005: Cannot add abstract member 'System.Threading.Tasks.Task<ModelContextProtocol.Client.ClientCompletionDetails> ModelContextProtocol.Client.McpClient.Completion.get' to lib/netstandard2.0/ModelContextProtocol.Core.dll because it does not exist on [Baseline] lib/netstandard2.0/ModelContextProtocol.Core.dll [/Users/runner/work/csharp-sdk/csharp-sdk/src/ModelContextProtocol.Core/ModelContextProtocol.Core.csproj]

Should we suppress this?

[halter73]

I think there's a real pre-existing bug lurking.

Maybe, but then why would the retry happen after 5 seconds? The DefaultReconnectionInterval is 1 second, so it definitely could be falling back to that. But even if that were happening (which I kinda doubt), that wouldn't account for most of the delay.

To me, this seems like the main issue is likely with the tests. It might be caused by a low core count CI machine and too much test parallelism causing thread pool starvation. Or maybe some tests not properly cleaning up after themselves causing similar results.