Implement accounts, characters, roles, and login lifecycle

[zoeyrose]

Outcome

Own secure account and character admission from authentication through attachment to the deterministic simulation.

Scope and invariants

• Define account/character stable IDs, normalized names, creation limits, role/permission model, bans, deletion protections, and audit events.
• Use a current password hashing policy with upgrade-on-login, secret-safe configuration, throttling, and constant-behavior error responses.
• Implement character creation, selection, attach/detach, duplicate login policy, reconnect/resume handoff, save points, and logout.
• Separate operator roles from gameplay data and require typed authorization at every privileged service boundary.
• Keep authentication/session tokens out of persistence exports, telemetry labels, crash reports, and protocol diagnostics.

Acceptance criteria

• Tests cover normalization collisions, brute-force throttling, password upgrade, duplicate sessions, disconnect during transitions, reconnect, deletion guards, role changes, and persistence conflicts.
• Transport Implement QUIC transport, sessions, and authentication #33 never directly mutates account or character records; all calls use this service.
• A deterministic wrapper scenario provisions an isolated account/character without reconstructing state paths.
• Security review documents hashing parameters, token lifetime/revocation, enumeration resistance, and audit retention.
• Classic import, if approved, enters through a separate validated adapter.

Dependencies and parallelization

Depends on #33 and #39; minimal actors can be stubbed. The Rust login UI and wrapper scenario can proceed against generated fixtures.

Independent implementation

New code and tests are MIT-licensed independent work. Preserve public behavior and issue-level design choices, but do not copy or mechanically translate GPL server/Python implementation or tests. Mixed-license content remains external data with its own notices.