Server mishandles `Initial`s w/DCID different from original DCID

[larseggert]

Timeline of events:

1. Initial handshake: Neqo client starts connection with DCID ca3c495d854410e310bec8c6776a and sends Initial packets containing CRYPTO frames with the
   ClientHello (packets pn=28, 29).
2. Packet loss: The test simulates packet loss - packet 29 is lost.
3. PTO and retransmission: Client's PTO timer fires, retransmits CRYPTO frames (packets pn=30, 31).
4. Server response: Server receives packet 30, sends ACK containing server's chosen DCID: 40000053242b4f7f.
5. DCID switch: Upon receiving the ACK, neqo changes connection to use the server's DCID for all subsequent packets (neqo-transport/src/connection/mod.rs:1997).
   State transitions from WaitInitial → WaitVersion.
6. Retransmission with new DCID: Client retransmits lost CRYPTO data (packets 32-33) using the new DCID 40000053242b4f7f.
7. Server decryption failure: The mvfst server receives packets 32-33 but cannot decrypt them:
   - Server qlog shows: DECRYPTION_ERROR_INITIAL
   - Error: "Failed to decrypt first packet from peer"
   - Server received 1252 bytes but extracted 0 bytes of crypto data
8. Connection timeout: Client continues sending PING probes but receives no response, eventually timing out with IdleTimeout after 59 seconds.

According to QUIC RFC 9000 Section 5.2:
"Initial packets are protected using the keys derived from the Destination Connection ID field from the client's first Initial packet."

Initial packet keys MUST be derived from the original client DCID (ca3c495d854410e310bec8c6776a), not from any DCID changes that occur later.

The attached ZIP file has the QNS data for the run.

CC @mjoras