Seeding and picking a server each happen once per connection. Neither had a
guard, so a client pipelining into the recv buffer could re-run the handshake
before the queued disconnect drained and reach both handlers again.
A second play-server is the one that mattered: this connection may already have
spent its auth id on a game login, and the id it would be handed back is the
spent one, which nothing will redeem. Rejecting the packet is the honest answer
-- the client is out of protocol order, not unlucky.
Account login and game login already guarded on SentFirstPacket.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
d337cf4a1e