fix(gateway): keep players connected when a move's session retires before activation

[oglassdev]

Fixes #292. When a player was moved into a session at the moment it retired through scope.finish(), control failed the activation with stale activation and the gateway disconnected the player. Players now keep their connection.

What the player sees

When the destination session retires	Result
Before the gateway starts configuration	The move fails as a move, and the player stays in play on the source session. Their source claim is never fenced.
During or after the configuration handshake (the issue's reproduction)	The player keeps their connection and is routed again as a login.
On a first login, while claiming or before activation	The login is claimed again, under a new operation ID.

The issue asked for the player to stay on their source session. That is not reachable in the second case: by the time activation runs, the move has already released the source claim and the client has left play state for configuration. Returning them to the source would need the JVM to take a player back after configuration, or activation before the source is fenced. This PR does not attempt either.

How

• Control reports a retired destination as its own outcome, DESTINATION_RETIRED, when claiming and when activating. A claim is lost to retirement when it never admitted its player, control did not cancel it while its session still ran, and its session is retired now. That is read from the session when asked, so it does not depend on the order a JVM report's deliveries and sessions are applied in. The only new state is Claim.canceled, set where control itself begins a withdrawal.
• A stale generation, a claim control canceled, and a claim a newer claim has superseded stay fatal.
• On the wire, ActivateResult gains retired and ClaimRefusal gains DESTINATION_RETIRED, so the gateway does not match on error strings.
• The gateway re-checks a move before starting configuration. If the move vanishes afterwards because its destination retired, it records the move as failed, withdraws the retired claim, and claims a destination again as a login on the same connection. It reroutes at most once per arrival; a second retirement or a failed reroute disconnects with "Server temporarily unavailable". Activation and the reroute share one wait of at most 45 seconds.

Worth a reviewer's attention

• A rerouted player gets login semantics: PlayerLogin and route hooks run again under a new membership, and no PlayerDisconnect fires for the old one.
• A connected player whose move failed for another reason, and whose destination has also retired, is rerouted rather than disconnected, as long as no newer claim owns them.
• A retired roster destination reroutes each member individually.
• The client sits in configuration without keepalives while the withdrawal and the new claim run, as existing cutover waits do.
• examples/arena still resets an emptied arena instead of finishing it. Reverting that is a behaviour change to the example, left for later.

Tests

• One JVM report that closes a delivery and ends its session together leaves the move retired.
• Members of a roster whose session retires are told so, not that their move was abandoned.
• A login whose delivery closes with its session while control prepares it is retired, and the gateway claims again.
• A claim canceled while its session ran stays stale when the session retires later; a retired claim stops being reported once a newer claim owns the player.
• Through the gateway's serve loop with a client and a fake JVM: a move whose destination retires during configuration keeps the player connected on a new login.

Checks

cargo test -p chunk-control (91 passed), cargo test -p chunk-proxy (84 passed), cargo test -p chunk-environment --lib (193 passed, 2 ignored, run before the last two commits), cargo clippy --all-targets --all-features -D warnings and cargo fmt --check on the touched crates, buf lint and buf format.

🤖 Generated with Claude Code