Control channel registration fails (ErrorResponse, unreadable) even on a minimally-patched official 0.1.1 Paper build

[hemamoon]

Minecraft server: Purpur 1.21.11, Java 25
Plugin: built from the official playit-companion source (Paper module), based on the 0.1.1 release tag
Hosting: container-based, no SSH/shell access, only the Minecraft process itself
Hosting provider confirmed no outbound traffic is blocked

Background:
The official 0.1.1-paper build from Modrinth doesn't even load on 1.21.11:

java.lang.NoSuchMethodError: 'boolean net.minecraft.server.dedicated.DedicatedServer.isEpollEnabled()'

This method appears to have been removed from DedicatedServer in newer server versions.

To test further, I rebuilt the plugin from the pristine 0.1.1 source with a single, minimal, non-functional change to PlayitPlugin.java:

```java
// before
return Epoll.isAvailable() && nmsServer.isEpollEnabled();
// after
return Epoll.isAvailable();

No other code was touched — no changes to PlayitAgent.java, ApiClient.java, or anything network/claim related.

Result: the plugin now loads correctly on 1.21.11. The claim flow also succeeds — the agent shows up correctly in my dashboard (confirmed status/name after claiming). However, shortly after claiming, every run consistently logs:

[PlayitPlugin] Failed to register control channel: gg.playit.proto.rest.ErrorResponse@17bf59ef
The dashboard keeps showing "Agent is offline" / "Not connected" indefinitely.

Since this reproduces on an unmodified (network-logic-wise) build, I suspect it might be related to the hardcoded client version identifier sent during registration in PlayitAgent.java:

```java
new PlayitAgentVersion(
    "fe4b4acd-19a7-45a8-9f31-c88cb9969855",
    0, 1, 0
)

If the backend has deprecated/stopped accepting this version fingerprint (which appears unchanged since the 0.1.0 release), that would explain why registration fails consistently regardless of which build variant is used.

Also worth noting separately: ErrorResponse doesn't override toString():

public class ErrorResponse {
    public String type;
    public String message;
}

So the log only ever prints the default ClassName@hashcode instead of the actual type/message fields, making this very hard to diagnose from the client side. A toString() override here would help a lot for anyone hitting similar issues in the future.

Happy to provide full logs or test further if useful.

Thanks!