[HyacinthHaru]

SpigotInjector#removeInjection() returned right after restoring the original channel list, so the code after it never ran, and the floodgate-init handler that injectClient() adds to the server channel was never removed at all. SpigotDataAddon#onRemoveInject() was also a no-op, so floodgate_data_handler stayed on any connection that was still in the handshake/login phase.

This mostly shows up after a plugin-manager reload: the new instance tries to inject again, netty rejects it with Duplicate handler name: floodgate-init, the exception is swallowed by the loop in inject(), and the old handler from the closed class loader keeps running while the new Floodgate believes it is injected. The same thing happens when enabling fails after inject() already ran, which is what caused the zip file closed errors reported alongside GeyserMC/Geyser#6716 on Paper 26.3.

removeInjection() now falls through to removeAddonsCall() and injected = false as intended, removes floodgate-init from every listening channel, and SpigotDataAddon removes its own handler like the other addons already do. No new state is introduced; the channel list that inject() wraps is walked in reverse.

Tested on Paper 26.2/26.3 by reloading Floodgate and re-joining with a Java and a Bedrock client.

I used Claude Code to help identify and fix the issue, but I performed the final testing.

[hasankayra04]

If AI was used at any stage in creating this PR, please read the AI Policy.

[HyacinthHaru]

If AI was used at any stage in creating this PR, please read the AI Policy.

I initially discovered this issue after upgrading my server to Minecraft 26.3. After asking Claude to analyze it, I confirmed the issue and had it fix the problem with a minimal diff.

I apologize for not noticing AI_POLICY. However, both the discovery of the issue and the post-fix testing were carried out on my own local test server.

Thank you for pointing this out. I updated the PR description to include a disclosure regarding the use of AI tools.