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.

Aucun fichier, point d’entrée ou test n’est nommé. Commencez par examiner la séquence d’implémentation et les prérequis (#200, #203, #204, #175, #202, #201 et #205), puis inspectez les chemins actuels de persistance de room, session, attempt et solve. Le travail est terminé lorsque les release gates passent, que le comportement des salles normales reste inchangé, que les sessions de compétition conservent leurs résultats et que la persistance MongoDB des salles et des résultats est supprimée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.