Define account, authentication, character, and session messages

[zoeyrose]

Outcome

Specify the complete pre-game and attachment lifecycle consumed by the fresh Go server and Rust client.

Messages and state machines

• Initial hello/version/capabilities/server identity metadata following the transport handshake.
• Authentication request/challenge/result appropriate to the server’s approved password/token design; never expose password material in general logs/fixtures.
• Session/resume token issuance, expiry/revocation, reconnect, duplicate login, and server drain behavior.
• Account/role-safe summary, character list entries with revisions, creation policy/options/result, selection/attachment, protected deletion, logout/detach, and session termination.
• Structured localized diagnostic codes/parameters rather than server prose for recoverable UI states.
• Request IDs/idempotency/revision preconditions for repeated or stale operations.

Security and bounds

• Exact limits on attempts, names, characters, metadata, tokens, list sizes, and messages.
• Enumeration-resistant result semantics and redaction requirements.
• Capability/version failures happen before credentials.
• Authorization context is server-owned and never accepted as a client claim.
• Character/world state begins only after a successful attachment generation.

Acceptance criteria

• Normative transition table rejects out-of-order, duplicate, replayed, stale, or unauthorized messages coherently.
• Go/Rust fixtures cover every success/error/transition and bounds; server/client headless integration completes login, character create/select, disconnect, and resume.
• Malformed messages cannot partially create/delete/attach a character.
• Secret fields are excluded from debug formatting/test snapshots or use explicit redaction.
• Schema supports actionable accessible client UI without revealing internal exceptions.