test: patch Netty's lost-read-interest race in the test server via a javaagent

[u9g]

Companion to #4018. That PR detects the login stall and reconnects; this one removes it on the test server.

The bug (vanilla ≤1.20.1, Paper included): Connection.sendPacket calls setAutoRead(false) on the main thread for each PLAY packet sent while the channel attr still says LOGIN, and queues setAutoRead(true) on the netty IO thread. Netty re-arms OP_READ only on a 0→1 flip of the flag, but the queued clearReadPending0 drops it unconditionally — so when doSendPacket_i runs between the main thread's toggles for i+1 and i+2, the channel ends up autoRead=true with no read interest, nothing re-arms it, and ReadTimeoutHandler(30) kills the connection. Reproduced deterministically on stock Netty 4.1.82 with latches, and on a real 1.19.3 server at ~1% of logins under CPU load (~10% with Connection DEBUG logging). Mojang rewrote protocol switching in 1.20.2 (MC-265209); Paper's archived ≤1.20.1 branches have no fix, and there is no property to toggle.

The fix: a -javaagent (test/netty-agent/NettyAutoReadFixAgent.java, source only) that rewrites AbstractNioChannel.clearReadPending0 with the JDK ClassFile API to skip removeReadOp() when autoRead is already true. Bytecode-level, so it works on whatever Netty 4.1.x the server bundles (4.1.9–4.1.82 across 1.12–1.20.1) and is a logged no-op on 1.8.8's 4.0.23. test/common/nettyAgent.js compiles and jars it at test time and the harness attaches it via JAVA_TOOL_OPTIONS, so minecraft-wrap is untouched. If no JDK is present it logs and the suite runs unpatched.

CI change: java-package: jre → jdk so javac/jar exist on the runner (still Java 25).

Validation

• 1.19.3 (Netty 4.1.82, bundler jar): patched, 70/70
• 1.16.5 (Netty 4.1.25, shaded jar): patched, 69/69
• 1.8.8 (Netty 4.0.23): no clearReadPending0, 69/69
• Loaded-server login loop with DEBUG logging: 8 stalls / 60 logins unpatched → 0 / 800 patched.

[rom1504]

I'm not sure we should do this. That makes the server non vanilla and it removes a cause of failure that real users might see.
Should we not just kill the server and retry instead?

[u9g]

I'm not sure we should do this. That makes the server non vanilla and it removes a cause of failure that real users might see. Should we not just kill the server and retry instead?

You’re right, although it’s clientside that we should restart, done in #4018