Implement SQLite persistence, schema migrations, checkpoints, and backups

[zoeyrose]

Outcome

Provide crash-consistent persistence for accounts, characters, world instances, and durable gameplay state with an operationally simple SQLite WAL design.

Scope and invariants

• Use one coordinated writer and explicit read/transaction APIs; gameplay code never assembles SQL.
• Version every schema migration, require transactional forward upgrades, and record application/content contract versions.
• Define optimistic revision checks, idempotency keys, checkpoint cadence, WAL/disk-full behavior, and startup recovery.
• Associate mutable snapshots with immutable content digests and reject unsafe mismatches with a diagnostic migration path.
• Provide online-safe backup, restore verification, integrity checks, and documented filesystem/permission requirements.

Acceptance criteria

• Failure injection covers process interruption, busy/locked database, disk full, I/O error, corrupt pages, failed migration, and stale revision.
• Atomic gameplay transactions never expose half-applied currency, inventory, quest, or location state.
• Backup/restore rehearsal reproduces the same domain state digest and does not include secrets in logs.
• Schema and query tests run under race detection; representative save/checkpoint latency meets explicit tick-independent budgets.
• No classic database, serialization, Flex, or Python loader is linked or imported.

Dependencies and parallelization

Depends on architecture #3 and state boundaries from #37; account #40 and snapshot #11 consume it. Classic import remains separate and cannot distort the canonical schema.

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.