Long Retry token can panic or exhaust memory in a QUIC client

Summary

A client kept the token from a Retry packet without any length limit and put it into the header of every Initial packet it sent afterwards. Initial datagrams are 1200 bytes. When the token and connection IDs left no room for the minimum payload, `PacketBuilder::new` computed a minimum packet size larger than the maximum, which only a debug assertion checked. On the next `poll_transmit`, debug builds panic, and release builds try to allocate more than 10 GiB in one call. With longer tokens the allocation fails and the process aborts.

A matching Retry packet can be built from the client's first Initial alone. The attacker can therefore be the server being contacted, or anyone who sees that Initial and can answer before the server does. Every application that makes outgoing connections with `quinn-proto` is affected, including all `quinn` clients. Servers do not process Retry packets.

The fix closes the connection with `PROTOCOL_VIOLATION` when an Initial token leaves too little room for frames. That covers Retry tokens and cached address-validation tokens, since both come from the peer. It also reserves room for CONNECTION_CLOSE after large Initial headers. Both changes are in 0.11.19.