Fix SslStream handling of empty TLS handshake records

[rzikm]

Recognizing exactly-five-byte TLS records exposed unchecked handshake-type reads in SslStream.ReceiveHandshakeFrameAsync. An empty handshake record (16 03 01 00 00) currently throws IndexOutOfRangeException during server authentication.

Validate the current record length before either ClientHello probe, retaining the protocol-specific TLS/SSLv2 offset. Empty handshake records now throw IOException immediately, without waiting for EOF or a sixth byte. Checking the record length rather than the buffered span also prevents trailing data from masking the malformed record. Five-byte frame recognition and application-data handling remain unchanged.

Regression coverage includes direct certificates, certificate/options callbacks, sync/async authentication, both handshake implementations, fragmented reads, trailing buffered data, and a peer that keeps its transport open. Tests use TLS 1.2 to exercise managed framing rather than Apple's separate Network Framework handshake path.

Validation

• All 18 new regression cases fail against the rebuilt original library and pass with the fix.
• Windows x64 library build and full local functional/unit suites pass: 5,410 passed, 40 existing platform/condition skips, zero failures.
• The existing five-byte post-handshake framing regression still passes. Linux/macOS were not run locally.

Fixes: #134784

Resolves #134784

Note

This pull request was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[wfurt]

LGTM