fix: CombatThread queue draining, per-instance Spigot404Write queues, and LagCompensator synchronization

[GamingOP69]

Summary

Resolves race conditions and thread safety issues in CombatThread, Spigot404Write, and LagCompensator.

Problem & Root Cause

• In CombatThread.run(), checking size() > 0 before calling poll() on a ConcurrentLinkedQueue is not an atomic operation. If the queue was drained by another thread or empty between calls, poll() returned null, resulting in NullPointerException when calling .run(), which permanently crashed the async combat thread loop.
• Spigot404Write used static packet queues and task lists across player connections, allowing packets intended for one player's channel to leak into another.
• LagCompensator.locationTimes used an un-synchronized ArrayListMultimap that was accessed and iterated simultaneously from both Netty I/O threads and the main server tick thread, causing sporadic ConcurrentModificationException crashes.

Solution

• Changed CombatThread.run() to poll directly into a local variable and check if (task != null) task.run().
• Made Spigot404Write packet queues and task collections per-instance fields tied to individual connections.
• Wrapped LagCompensator.locationTimes with Multimaps.synchronizedListMultimap and added proper synchronized blocks around its iteration blocks.

[GamingOP69]

CombatThread.run() it was doing size() > 0 then poll() on a
ConcurrentLinkedQueue Those two operations aren't atomic the queue can drain between
them poll() returns null, you call .run() on null, and the combat thread crashes and
never comes back. Fixed to just poll directly and null-check the result.

[GamingOP69]

Spigot404Write had its packet queue and task list as static fields, meaning
every player connection was sharing the same queues. Packets meant for one player could end up going to another players channel Changed those to per-instance fields tied to each
connection.

[kalibrieren]

please sync this PR - LagCompensator was removed