Fix Windows CI flaps

[mtmk]

Cherry-pick of #1145 (against release/3.0) onto main, squashed into one commit. See that PR for the analysis and verification.

Fixes #1142.

[synadia-claude-reviewer]

Claude finished @mtmk's task in 1m 16s —— View job

---

PR Review: Fix Windows CI flaps

• Gather context and read PR diff
• Examine changed files for correctness and issues
• Post review summary

---

Summary

This is a targeted, well-reasoned fix for Windows CI flakiness. All changes are confined to test infrastructure — no production code is touched.

Changes reviewed:

File	Change	Assessment
xunit.runsettings	MaxParallelThreads 4.0x → 1.0x	Correct fix for resource contention; will slow total CI runtime but stabilizes flaky tests
NatsUtils.cs	ConnectRetryAsync default timeout 30s → 60s	Safe; only affects how long tests wait for retry connections
5 test files	Added explicit ConnectTimeout = TimeSpan.FromSeconds(30)	Prevents default (likely short) timeout from causing spurious failures on loaded Windows runners
TlsPreferTest.cs	Added TimeoutException to TLS-evidence exception types	See note below

One item worth a second look:

In TlsPreferTest.cs (line 308), TimeoutException is added to the set of exceptions treated as evidence that the TLS path was attempted. The comment explains the reasoning well: a 30-second connect timeout expiring during the TLS handshake (after INFO was already read) implies the TLS upgrade path was entered. The existing clientSentConnect.Should().BeFalse() guard (line 286) rules out the false-positive scenario where plaintext CONNECT succeeded before the timeout. The logic is sound, but it does make this assertion slightly weaker — a TimeoutException before even reading INFO would also pass it. Given the MaxReconnectRetry = 0 setting and the controlled fake-server setup, this is unlikely to cause a false pass, but it's worth keeping an eye on.

No correctness bugs, security issues, or async/await problems found. The MaxParallelThreads reduction from 4.0x to 1.0x is the highest-impact change and will noticeably increase total CI wall-clock time. If CI time becomes a concern, a middle ground (e.g. 2.0x) could be revisited after confirming stability at 1.0x.

Looks good to merge.

[scottf]

LGTM