fix(ping): reject when the connection closes before a status response

[u9g]

Problem

ping() settles on exactly three things: server_info, ping, or a client error. A server that accepts the connection and then closes it without answering is invisible to all three — the promise sits until closeTimeout (120 s by default) and then rejects with ETIMEDOUT, blaming a timeout that never actually happened, long after the server already told us it wasn't going to answer.

This isn't hypothetical: vanilla servers do it on every startup. A status request is closed without a reply — no packet, just a FIN — until the server has built the status snapshot it serves, and that doesn't happen until startup has fully finished, slightly after the Done (…)! line is logged.

So pinging a server the moment it reports being up can land in that gap. Probing a real server every 25 ms across a boot: 26.1 closes status connections until 52 ms after the Done line and first answers at 77 ms (it saves every dimension in between), while 1.21.8 is already answering 11 ms before it.

This surfaces downstream as mineflayer's external tests intermittently failing on 26.1 with a bare mocha hook timeout (PrismarineJS/mineflayer#3976).

Fix

Reject on end when no status has arrived yet:

client.on('end', function () {
  if (gotStatus) return
  clearTimeout(closeTimer)
  reject(new Error('Connection closed before the server sent a status response'))
})

If the status did arrive and the server closes before the pong, the existing noPongTimeout path already resolves with the status — that case is deliberately left alone, so this is only ever converting a 120 s misleading timeout into an immediate, accurate error.

Test

test/pingTest.js points a ping at a socket server that accepts the handshake and hangs up. Without the fix it fails after the full closeTimeout with ETIMEDOUT; with it, it fails in ~400 ms with a message that says what happened.

✔ fails as soon as the server closes the connection without answering (408ms)