Fix chat submission closing screens opened by commands

[Eccys]

Type of change

• Bug fix
• New feature

Description

Preserve screens opened by client commands when the chat input is submitted.

Typing .reconnect with Meteor Rejects installed exposes the problem: the command opens a ConnectScreen synchronously, but ChatScreen.keyPressed() then continues and unconditionally calls Gui.setScreen(null). The new connection screen is replaced before it can continue ticking through the connection process.

The command itself belongs to Meteor Rejects. Meteor dispatches client commands synchronously from ClientPacketListener.sendChat, so the screen replacement happens inside the original chat submission. The same problem applies to other commands that open a screen immediately.

Wrap the chat-close call with a condition that the current screen is still the submitting chat screen. Normal chat submission still closes chat. If a command has opened a connection screen, another chat screen, or any other screen, that screen stays open. The keep-chat-open path is unchanged.

Related issues

No existing issue found for this chat-submission problem.

How Has This Been Tested?

• ./gradlew build --no-daemon passes on Java 25 against the current Minecraft 26.2 target. The build has no existing automated test sources.
• Inspected the installed Meteor Rejects 0.3 command and Minecraft 26.1.2 chat/connection bytecode from the reported setup. The addon immediately opens the connection screen and vanilla subsequently clears it. Confirmed the same chat-submit sequence in Minecraft 26.2.
• Ran a focused local regression harness using the actual Minecraft 26.2 chat-submit bytecode and the compiled onCloseChat guard with minimal UI doubles. Six scenarios were run before and after the guard: ordinary chat, a replacement screen, another chat screen, a command that already closed chat, keep-open chat, and keep-open chat with a replacement screen. All 12 checks passed; the baseline reproduced the screen overwrite and the guarded path preserved replacements. The harness also checked the compiled injection target and that vanilla has exactly one matching close call.
• This is control-flow validation, not a full Mixin runtime or live multiplayer test. Live reconnection with the patched client remains unverified.

Checklist:

• My code follows the style guidelines of this project.
• I have added comments to my code in more complex areas.
• I have tested the code in both development and production environments.