Fix Android client game events failing to deserialize in cross-platform network play

[MostCromulent]

Summary

Fixes a bug where Android clients connecting to a desktop host cannot see or interact with their hand (and other zones). The game loads and the match screen appears, but all zone-change events (cards entering hand, battlefield, etc.) are silently dropped, leaving the mobile player with an empty/non-interactive board. The desktop host sees everything correctly.

This appears to only affect cross-platform play between desktop (JVM) and Android — both sides built from the same source.

Root Cause

The GameEventProxy inner serialization (introduced in #10018) serializes game events into byte arrays using ObjectOutputStream, then deserializes on the client with ObjectInputStream. This triggers a serialVersionUID mismatch between desktop and Android:

• Desktop (JVM 17+): Java records get a hardcoded serialVersionUID = 0L when none is explicitly declared.
• Android (D8 desugaring): Records are desugared to regular classes, which get an auto-computed serialVersionUID based on class structure (e.g. -841910661983749810 for GameEventZone).

The result is InvalidClassException for every event type — GameEventZone, GameEventShuffle, GameEventFlipCoin, GameEventGameStarted, GameEventCardStatsChanged, GameEventCardChangeZone. The proxy's unwrapAll() catches these and drops the events with a warning log. Since setGameView/copyChangedProps still works (it doesn't go through the proxy), the underlying data model is correct, but the UI never receives the events that trigger visual updates.

Client log showing the failure:

[WARN] GameEventProxy: Failed to unwrap GameEventProxy: forge.game.event.GameEventZone; 
  local class incompatible: stream classdesc serialVersionUID = 0, 
  local class serialVersionUID = -841910661983749810

Fix

Override readClassDescriptor() in GameEventProxy.IdResolvingInputStream to detect serialVersionUID mismatches and substitute the local class descriptor. This bypasses the false-positive UID check while preserving normal deserialization — the classes have identical fields, only the UID computation differs.

This is safe because the proxy is used for same-version communication — server and client are built from the same source. The UID mismatch is a false positive caused by JVM vs Android computing different UIDs for structurally identical classes. In the worst case (a genuinely incompatible class change between versions), deserialization would fail at the field level with an IOException rather than at the UID check — the event would still be caught and dropped by the existing error handling in unwrapAll(), same as today.

This is an established pattern in the Forge codebase, already used in:

• SaveFileData.java — Adventure mode save file compatibility
• CObjectInputStream.java — Netty network layer (desktop side)

Verification

Built Android APK from this branch and tested on an emulator connecting to a desktop host:

• Hand cards visible and interactable on mobile client
• No Failed to unwrap GameEventProxy warnings in client log
• Desktop host unaffected

---

🤖 Generated with Claude Code

[Hanmac]

i don't have a problem with hardcoding serialVersionUID for Events
i will check if i can do this in an interface instead of record "class"