kick sessions that stop responding to keep alives

[Shivam-Shukla0]

Fixes #303
Half-open controller connections (e.g. after an unstable home internet outage) could remain attached for minutes until a Broken pipe occurred. During that time, teleports were forwarded to the dead controller and never confirmed, leaving the player frozen on the destination server until it kicked the session.
This PR tracks the last keep alive response time on each ServerSession and disconnects sessions that haven't responded within server.extra.timeout.seconds (default 30s), mirroring vanilla server behavior. The check runs in both keepAlive modes and for spectators. After the kick, the bot takes over and resyncs queued teleports well before the destination server's kick threshold, preserving the active session.
Tested by suspending the controlling client's process to simulate a half-open connection: the session is kicked after the timeout, the bot resyncs teleports, and the connection to the destination server survives. Verified normal player and spectator connections are unaffected in both independent and passthrough modes.

[rfresh2]

this is not a real issue, nor the cause of #303

keepalives are already sent by zenith when a controlling player stops sending them, regardless of their KeepAliveMode https://github.com/rfresh2/ZenithProxy/blob/47ae67340b4cf82f9972fbfad1ff5453ce13779d/src/main/java/com/zenith/network/ClientKeepAliveTask.java

you can easily test this by cancelling outgoing keepalives with a client like rusherhack's AntiPacket module

the cause of #303 is an internet connection issue between zenith and 2b2t, of which zenith has no control over. https://wiki.2b2t.vc/Disconnects/#connection-issue

zenith also already detects and dc's controlling players that stop responding over the network

if you reduce serverConnection timeout <seconds> (maybe to a few seconds) you can reduce how long it takes until the zenith bot takes over for them

but zenith cannot do anything about connectivity issues between it and the mc server (i.e. 2b2t)

[Shivam-Shukla0]

@rfresh2 Thank you for taking the time to explain this — that makes sense, especially the read timeout already covering unresponsive controllers and the actual cause being the zenith↔2b2t connection. I misread the log's [Client] context. Apologies for the noise, and I appreciate the pointers; I learned a lot about the keep alive and teleport handling while digging into this.