minecraft: Revert deferred packet re-check, expect ResourcePacksInfo with LoginSuccess; fix pong game type fields

[HashimTheArab]

Follow-up to yesterday's merges (#406 and #515). Two independent fixes.

Revert the deferred packet re-check (#406); expect ResourcePacksInfo with LoginSuccess

#406 made expect() run every deferred packet through handle() on the calling goroutine. That breaks two assumptions the login handlers are built on:

• A handler runs after the state change that expected it is complete. handleLogin calls expect(ClientToServerHandshake) before enableEncryption, so a handshake that was already deferred was answered inside expect(): the server wrote PlayStatus(LoginSuccess) and ResourcePacksInfo and marked the connection authenticated before ServerToClientHandshake was written. Reproduced against master with a Conn over net.Pipe: wire order [PlayStatus, ResourcePacksInfo, ServerToClientHandshake]. handleRequestNetworkSettings has the same shape (expect(Login) before NetworkSettings is written and compression enabled).
• Handlers run on the receive goroutine only. StartGame, Dial and the pack download goroutine call expect(), so a matching deferred packet had its handler run there, concurrently with the receive loop (plain-field writes to readyToLogin, loggedIn, gameData, the decoder's compression state), and listenConn/handleConn only observe readyToLogin/loggedIn transitions around their own receive() call, so a transition made in another goroutine's drain is never signalled.

I first tried to keep the re-check and schedule it safely (flag on the receive loop, then a handler mutex). Each variant fixed those and opened another hole: a packet deferred during login stranded until the next inbound packet, spawn packets written before StartGame, a lost wake-up on the lock. The mechanism is the problem, so this reverts it.

The case #406 targeted does not need it. The vanilla client handles ResourcePacksInfo whenever it arrives and reacts to PlayStatus(LoginSuccess) only by sending ClientCacheStatus, so this expects both after Login is sent (and after ServerToClientHandshake) and LoginSuccess no longer narrows the set to ResourcePacksInfo. A server that sends ResourcePacksInfo first is handled on arrival, and PlayStatus stays expected through the pack phase so the LoginSuccess that follows still sends ClientCacheStatus. startGame now expects the client's replies before writing StartGame, which closes the pre-#406 gap where a fast reply could be deferred. The vanilla client only sends RequestChunkRadius from its StartGame handler, so nothing earlier than that needs handling; the pre-StartGame window in #462 is a separate path (read channel, not the deferred queue) and is untouched.

Checked locally (net.Pipe harness, not committed): Info before LoginSuccess enters the pack phase and a late LoginSuccess sends ClientCacheStatus without resetting it; normal order unchanged; an early plaintext handshake stays a stray and only ServerToClientHandshake follows Login; spawn packets follow StartGame/ItemRegistry; a Listen/Dial login and spawn round-trip over RakNet passes under -race.

Server list pong game type fields (#515)

The field after the game mode is a separate flag, not the game mode number: the client drops a pong with ten or more fields unless that field is exactly 1 (Cloudburst serialises it separately as nintendoLimited), so a listener with the default GameType of Survival (0), or Adventure (2), disappeared from the server list. It is 1 again.

ParsePongData also rejected any pong whose mode was not exactly Survival, Creative or Adventure, discarding the name and player counts of servers that advertise Spectator or no mode at all (PocketMine sends nine fields). The mode is now optional and unknown modes parse as Survival, matching the client; Spectator is supported in both directions via the packet.GameType* constants. The minimum field count was seven while the sub-name at index seven was read unconditionally, which could panic.