Cut over rooms, RaceSessions, attempts, and solves to PostgreSQL

Part of #199.

Goal

Make PostgreSQL the single source of truth for rooms, race sessions, attempts, solves, and their participant state as one coordinated aggregate.

Do not leave room state authoritative in MongoDB while session/result state is authoritative in PostgreSQL.

Preconditions

• Production dual writes and deployment behavior from #176 are stable.
• The new schema and persistence boundary are deployed.
• #175 has backfilled historical data into the RaceSession model.
• Reconciliation shows no unexplained missing, duplicate, or mismatched records.
• A production-shaped rollback rehearsal has succeeded.

Rollout

1. Add shadow reads that compare PostgreSQL with the current MongoDB path without returning private data in logs.
2. Measure mismatches, read latency, transaction failures, and result-submission errors.
3. Provide one aggregate-level configuration switch for authoritative PostgreSQL behavior.
4. Rehearse the switch with production-shaped data and concurrent writes.
5. Enable PostgreSQL authority in production.
6. Monitor room create/join/rejoin, session changes, attempts, solve submission/editing, expiry, and moderation.
7. Keep the compatibility path only for a bounded rollback window.

Acceptance criteria

• Every room/session/attempt/solve read comes from PostgreSQL in authoritative mode.
• Every corresponding mutation commits to PostgreSQL before success is acknowledged.
• MongoDB failure does not affect these operations after cutover.
• Redis and Socket.IO multi-process behavior remains correct.
• Existing normal-room, private-room, reconnect, moderation, and result-outbox flows pass.
• Concurrent submissions and session switches do not create duplicates or cross-session solves.
• Metrics expose errors and latency without solve data or identity.
• Rollback triggers, procedure, and data compatibility are documented and rehearsed.
• The deployed commit and verification results are recorded.

Non-goals

• Moving user authentication records to PostgreSQL.
• Removing the temporary migration implementation; that follows after the rollback window.

ファイルやテストは指定されていません。まず #176、#175、#199 を読んでから、デプロイ済みのスキーマ、永続化境界、現在の MongoDB パスを調査してください。記載された受け入れ基準が検証済みであることが完了の条件です。これには、PostgreSQL の権威性、並行操作の安全性、メトリクス、ロールバックのリハーサル、記録されたデプロイ結果が含まれます。