Fix client Initial key discard to trigger on any Handshake packet send

[guhetier]

Description

Fixes #5664, #5899

Fix a circular dependency in client Initial key discard that causes RandomLoss handshake test failures.

Root cause: Per RFC 9001 §4.9.1, a client MUST discard Initial keys and clear the congestion control and recovery states when it first sends a Handshake packet. MsQuic only discarded Initial keys inside QuicCryptoWriteFrames — which only runs when writing CRYPTO frames to a HANDSHAKE packet, not for every HANDSHAKE packet.

If the INITIAL data is big and there is packet loss on the network, it is possible for that the number of INITIAL bytes in flight from the client perspective is higher than the congestion window.
When the client receives the server's Handshake flight and TLS produces the Finished message, the send path tries to flush it as a HANDSHAKE CRYPTO frame. However, CRYPTO frames are subject to congestion control (per RFC 9002 §3 — only ACK and CONNECTION_CLOSE bypass CC).
This result in a HANDSHAKE packet containing only an ACK frame (which bypasses CC) — but no CRYPTO frame carrying the Finished.

This creates a deadlock:

• The client can't send the CRYPTO frame that would cause it to discard the INTIAL packet pending retransmission
• The server received a HANDSHAKE packet and drop every retransmitted INTIAL packet from the client

Eventually, the connection times out.

Fix: Move the client Initial key discard from QuicCryptoWriteFrames (crypto.c) to QuicPacketBuilderFinalize (packet_builder.c), so it triggers on ANY Handshake packet send (including ACK-only). This breaks the circular dependency: the ACK-only HANDSHAKE packet triggers the discard → Initial BytesInFlight released → CC unblocks → queued flush sends the Finished.

Testing

Existing tests cover this change — all 353 Handshake tests pass (including all RandomLoss and HandshakeSpecificLossPatterns variants), plus 1,328 Basic/Misc/Api tests.

Documentation

No documentation impact.