Track competition rooms foundation and PostgreSQL cutover

## Goal

Make rooms durable containers that can host multiple independent racing sessions, while PostgreSQL becomes the sole source of truth for rooms, race sessions, attempts, and solves.

The existing **Create room → copy link → friend joins → race** flow must remain unchanged for normal rooms.

## User-visible outcome

- Normal rooms continue to work exactly as they do today.
- Every normal room automatically receives one active race session.
- Changing events ends the current race session and creates another instead of deleting attempts.
- A feature-flagged competition room can contain multiple event sessions.
- Users can switch between competition event sessions without losing results.

## Target model

- **Room:** identity, name, access, privacy, lifecycle, owner/admin, optional competition reference.
- **RaceSession:** room, event, format, scramble source, state, scheduled and actual start/end times.
- **Attempt:** race session, ordinal, scramble.
- **Solve:** attempt, user, time, penalties, timestamps.
- **RoomParticipant:** membership, moderation, and room role.
- **SessionParticipant:** competing, waiting, and session eligibility.

Use `RaceSession` in code to distinguish racing sessions from authentication sessions.

## Data ownership after completion

PostgreSQL is authoritative for:

- rooms;
- race sessions;
- attempts;
- solves/results;
- room and race-session participant state.

MongoDB may continue to store users and authentication data, but it must no longer read or write the domains above after the cutover is complete. Redis remains responsible for realtime coordination and transient state where appropriate.

## Implementation sequence

- [x] #200
- [ ] #203
- [ ] #204
- [ ] #175
- [ ] #202
- [ ] #201
- [ ] #205

## Release gates

- [ ] Existing production dual writes are stable and the rollout in #176 is complete.
- [ ] Room ownership/admin behavior from #195 is settled.
- [ ] New PostgreSQL schema is backward-compatible during migration.
- [ ] Historical data is backfilled and reconciliation finds no unexplained differences.
- [ ] A production-shaped rollback rehearsal succeeds.
- [ ] Normal-room regression and competition-room vertical-slice tests pass.
- [ ] MongoDB room/result persistence and temporary dual-write code are removed.

## Existing related issues

- #175: historical backfill and parity
- #160: persistent solve and session history
- #174: PostgreSQL solve-history API, to follow the new model
- #176: production rollout prerequisite
- #195: room owner/admin semantics prerequisite

## Non-goals

- Full competition discovery or home-page redesign.
- Friends, invitations, push notifications, or Discord integration.
- Moving user authentication data out of MongoDB.
- Building the complete solve-history UI or csTimer export.

ファイル、エントリポイント、テストは指定されていません。まず実装の順序と前提条件 (#200、#203、#204、#175、#202、#201、#205) を確認し、その後、現在の room、session、attempt、solve の永続化パスを調査してください。完了の条件は、release gates を通過し、通常の room の動作が変わらず、competition session が結果を保持し、MongoDB による room/result の永続化が削除されていることです。

索引モデルが issue の本文から書いたものです。