Fix chat race conditions not addressed by #1042

[WouterGritter]

Fix chat race conditions not addressed by #1042.

Despite #1042 serializing chat/command processing through ChatQueue, two issues allowed out-of-order packets to reach the backend:

1. Rate-limited commands bypassed ChatQueue entirely

RateLimitedCommandHandler returned false when a command was rate-limited and forward-commands-if-rate-limited was enabled (the default). This caused the Netty dispatch path to write the packet directly to the backend via handleGeneric, racing ahead of any earlier commands still waiting in the queue for their CommandExecuteEvent to complete. Under rapid command bursts (e.g. litematica's schematic paste), this produced the exact out_of_order_chat kick described in #1042.

Fix: route rate-limited commands through ChatQueue via a new forwardRateLimited path, skipping plugin event firing but preserving write order.

2. ChatQueue.writePacket blocked the Netty event loop

writePacket submitted a runnable to the event loop that called awaitUninterruptibly() on the resulting ChannelFuture. Under backpressure (socket buffer full), Netty's deadlock guard throws BlockingOperationException before actually blocking, which was silently swallowed by .exceptionally(ignored -> null), making the "wait for send" step a no-op and allowing the queue to advance prematurely.

Fix: replace the blocking call with addListener, completing the CompletableFuture asynchronously when Netty confirms the write, with no event loop blocking.

---

Set to a draft as this does bypass rate-limiting somewhat by still forwarding some packets to the backends. I'm not sure if we want to merge this, however this should solve what's described in #1042.

I'd also love feedback from @7wOv6ySCjo (#1042 (comment)) as they are experiencing daily disconnects due to this issue.