Track competition rooms foundation and PostgreSQL cutover

No se nombran archivos, puntos de entrada ni pruebas. Empieza revisando la secuencia de implementación y los requisitos previos (#200, #203, #204, #175, #202, #201 y #205), y después inspecciona las rutas actuales de persistencia de room, session, attempt y solve. El trabajo estará terminado cuando pasen los release gates, el comportamiento de las salas normales no cambie, las sesiones de competición conserven sus resultados y se elimine la persistencia de salas y resultados en MongoDB.

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

• #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.