supportsForge disables packet ID range check — out-of-range IDs cause AIOOBE; EntityMap off-by-one

The patch that adds Forge support (0016-Allow-invalid-packet-ids-for-forge-servers.patch) introduces two issues when supportsForge is active:

1. Packet ID range bypass

DirectionData.hasPacket returns:

return supportsForge || i >= 0 && i <= MAX_PACKET_ID;

When supportsForge is true, the range check is completely short-circuited. createPacket then indexes protocolData.packetConstructors[id] (array size MAX_PACKET_ID+1 = 256) with an unchecked packet ID from the wire. A negative varint or value > 255 → ArrayIndexOutOfBoundsException.

supportsForge is set when a forge user connects to a forge server via ServerConnector.handleLogin.

2. EntityMap off-by-one

The same patch adds a guard in EntityMap.rewrite:

if (packetId < 0 || packetId > ints.length || packetId > varints.length) return;

Uses > instead of >=, so packetId == ints.length passes the check but then accesses ints[ints.length] → AIOOBE.

Impact

Both are caught by Netty error handling → the affected connection is closed. Memory-safe; no data leak or cross-player impact. A forge client or forge backend can trigger self-disconnection with an out-of-range packet ID.

Suggested fix

1. When supportsForge and the ID is outside [0, MAX_PACKET_ID], skip/forward the raw packet instead of indexing into the constructor array.
2. Change the EntityMap guard to >=:

if (packetId < 0 || packetId >= ints.length || packetId >= varints.length) return;

Checked at Waterfall master@150a002.

Trace DirectionData.hasPacket and createPacket, then follow supportsForge from ServerConnector.handleLogin. Inspect EntityMap.rewrite and the referenced Forge-support patch; verify that out-of-range packet IDs no longer cause array access failures and that the EntityMap boundary case is handled without AIOOBE.