Fix server/discover timeout interrupting OAuth

[halter73]

Summary

Start DiscoverProbeTimeout only after the server/discover request has been sent. This keeps transport setup and OAuth authorization under the overall InitializationTimeout, while preserving the short response timeout used to fall back when an older server silently drops server/discover.

The regression test now deliberately keeps protected-resource metadata discovery in flight longer than the probe timeout and verifies that the fallback paths are requested exactly once.

Main CI failure

This fixes the failure in Build and Test run 29739945453, Ubuntu Debug job 88344129696:

Assert.Equal() Failure: Collections differ
Expected: ["/.well-known/oauth-protected-resource/mcp", "/.well-known/oauth-protected-resource"]
Actual:   ["/.well-known/oauth-protected-resource/mcp", "/.well-known/oauth-protected-resource", "/.well-known/oauth-protected-resource/mcp", "/.well-known/oauth-protected-resource"]

The logs show the initial OAuth flow beginning for server/discover, then the five-second probe timeout starting initialize before the first token exchange completed:

[11:53:26] ... sending method 'server/discover' request.
[11:53:26] ... POST https://localhost:7029/token
[11:53:31] ... sending method 'initialize' request.
[11:53:32] ... POST https://localhost:7029/token - 499 ... 5830.9035ms

That overlap launched a second OAuth flow and repeated protected-resource metadata discovery.

Tests

• dotnet build --no-restore
• OAuth regression test on net8.0, net9.0, and net10.0
• July 2026 protocol fallback tests on net472, net8.0, net9.0, and net10.0
• Full non-manual ModelContextProtocol.Tests suite on net9.0 (2,286 passed)

[halter73]

@PranavSenthilnathan I'm also supportive of increasing the test timeouts, but I think it's a functional issue to have the probe timeout affected by the OAuth flow. I think it makes sense for the initialize timeout to still be in force, but how long the OAuth flow takes shouldn't affect protocol negotiation.

[PranavSenthilnathan]

Can we move these closer to the use site in the local function?

[PranavSenthilnathan]

This fixes DiscoverProbeTimeout prematurely canceling OAuth, but it no longer bounds the Streamable HTTP response wait. SendToRelatedTransportAsync awaits and processes the POST response before returning, so the timeout starts only after that response has been read and queued. If the server never responds, the client waits for InitializationTimeout instead of falling back after DiscoverProbeTimeout.

Passing the probe token into the entire send would reintroduce the OAuth bug because that operation may receive a 401, perform separate OAuth requests, and retry the POST internally. The HTTP/OAuth layer likely needs to apply the probe timeout while awaiting each MCP POST response, exclude the OAuth requests, and use a fresh timeout for the authenticated retry, while InitializationTimeout remains active throughout.

AI-assisted review comment.