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.

No files, entry points, or tests are named. Start by reviewing the implementation sequence and prerequisites (#200, #203, #204, #175, #202, #201, and #205), then inspect the current room, session, attempt, and solve persistence paths. Done means the release gates pass, normal-room behavior is unchanged, competition sessions retain results, and MongoDB room/result persistence is removed.

Vom Indexierungsmodell aus dem Issue-Text verfasst.