tests: fix TlsPreferTest flap on net481

[mtmk]

The server task in Prefer_mode_attempts_tls_upgrade_when_server_advertises_tls_available raced the client's failed TLS-handshake socket teardown: a FIN surfaced as ReadLineAsync returning null, while an RST threw IOException. On net481/Windows the reset path is common, producing the intermittent failure. Detect TLS positively from the first byte (0x16 Handshake record) instead of inferring from how the socket closed.

[synadia-claude-reviewer]

Claude finished @mtmk's task in 2m 15s —— View job

---

PR Review

• Gather context and read changed files
• Analyze the fix for correctness
• Check for async/await issues
• Post review

---

Approach is sound. Detecting TLS positively from the first byte (0x16 = TLS record ContentType Handshake) is protocol-correct for TLS 1.0, 1.2, and 1.3 (all use 0x16 0x03 0x01 for the outer ClientHello record), and cleanly avoids the race between a FIN (ReadLineAsync → null) and an RST (IOException) that caused the net481 flap.

One issue worth fixing:

catch (IOException) at line 230 does not catch OperationCanceledException. If the 10-second CTS fires while stream.ReadAsync(…, cts.Token) is in-flight (slow CI agent, etc.), the OCE propagates uncaught from the lambda, serverTask faults, and await serverTask (line 275) re-throws — producing a confusing failure rather than a clean timeout. An inline suggestion has been left on the exact line.

Minor observation:

using var sr = new StreamReader(stream, encoding) in the 'C' (plaintext) branch (line 243) will dispose the underlying NetworkStream when sr goes out of scope, before the outer using var tcp does. This is harmless in practice (double-dispose of NetworkStream is a no-op and tcp closes immediately after), but new StreamReader(stream, encoding, leaveOpen: true) would be more precise if this branch is ever expanded.

[Jarema]

LGMT!

[synadia-claude-reviewer]

Only IOException is caught here, but stream.ReadAsync(…, cts.Token) can also throw OperationCanceledException when the 10-second CTS fires. If the test is slow (e.g. on a loaded CI agent) and the read hasn't completed before the timeout, the OCE propagates uncaught from the lambda, serverTask faults, and await serverTask on line 275 re-throws — producing a confusing test-failure message instead of a clean timeout.

Consider catching both, or catching the base type:

Suggested change

	read = await stream.ReadAsync(firstByte, 0, 1, cts.Token);
	try
	{
	read = await stream.ReadAsync(firstByte, 0, 1, cts.Token);
	}
	catch (Exception ex) when (ex is IOException or OperationCanceledException)
	{
	output.WriteLine($"[SERVER] RCV failed: {ex.Message}");
	read = 0;
	}

[mtmk]

this would still be confusing. not worth it.