Investigate username issue

Root-caused and fixed on develop (economy-explorer 87e573c).

Why it was device-dependent (desktop works, mobile doesn't, same account): the Auth.js session JWT was storing the full Keycloak access_token and refresh_token — two large JWTs — that the explorer never actually uses (it reads the economy DB directly, never calls Keycloak APIs). That bloated the NextAuth session cookie past the ~4 KB browser limit, so Auth.js split it into chunks. Mobile browsers / Safari (ITP + stricter cookie caps) drop or truncate those chunks, so auth() couldn't decode the session → getViewer fell back to anonymous → the user saw none of their own (linked) data. Desktop browsers tolerate the larger/chunked cookie, so it worked there. Hence "same account, different device, different result."

It's not the durable link: explorer_identity is keyed on keycloak_sub (PK; there's only a non-unique index on the player UUID), so findIdentityBySub is fully deterministic per Keycloak account — once the row exists, every session for that sub resolves the same player regardless of device. The failure was the session itself not surviving on mobile.

Fix: drop the access/refresh tokens (and the unused refresh dance) from the session JWT — keep only sub + the minecraft_uuid/minecraft_name claim. The cookie is now tiny and survives mobile; session lifetime is governed by Auth.js's own JWT maxAge. Existing users on a broken/truncated cookie just need to sign in again once.

Typecheck + 65 unit tests green.

Note on .FiftyNine595: that's a Floodgate (Bedrock) dot-prefixed name. This fix restores the session reliably; if that specific player still can't see their firm after re-login, the remaining angle is a Java-vs-Floodgate UUID mismatch between the firm's proprietor UUID and the linked UUID — worth a quick check once they re-test, but separate from this session-cookie bug.

Related: the still-open INFRA item to add UNIQUE(player_uuid_bin) on explorer_identity (stops two Keycloak subs claiming the same player) is a separate integrity hardening — the viewer comment that claimed this constraint already exists has been corrected.