Remove MongoDB room/result persistence and temporary dual writes

Part of #199.

## Goal

Complete the PostgreSQL migration after the authoritative cutover has remained healthy for the agreed rollback window.

## Scope

- Remove MongoDB reads and writes for rooms, race sessions, attempts, solves/results, and their participant state.
- Remove embedded attempt/result data and room racing fields from the Mongoose model.
- Remove the PostgreSQL dual-write implementation and flags that only supported MongoDB authority.
- Remove shadow-read comparison code and migration-only metrics after preserving any generally useful health metrics.
- Retain historical migration and reconciliation tooling only when it remains useful and safe.
- Update backup, restore, development, deployment, and architecture documentation.

## Safety requirements

- Confirm no supported rollback image requires MongoDB room/result data.
- Advance any rollback floor before destructive cleanup.
- Capture and verify a final pre-cleanup backup.
- Make destructive MongoDB cleanup a separate, explicit, idempotent operation.
- Do not delete historical PostgreSQL attempts or solves.
- Verify production no longer queries the removed collections or fields before cleanup.

## Acceptance criteria

- [ ] Application code contains no MongoDB room/session/attempt/solve reads or writes.
- [ ] PostgreSQL failures correctly fail affected durable operations rather than silently falling back.
- [ ] Migration-only dual-write and shadow-read flags are removed.
- [ ] Cleanup can dry-run, apply, verify, and rerun idempotently.
- [ ] A repository search and runtime instrumentation find no removed-path usage.
- [ ] Backups and restore instructions treat PostgreSQL as authoritative for these domains.
- [ ] Development and test environments no longer require MongoDB for room racing behavior.
- [ ] Normal and competition room end-to-end tests pass after MongoDB room data is unavailable.

## Dependencies

- Successful PostgreSQL cutover and completion of its rollback observation window.

Commencez par confirmer la fenêtre d’observation du basculement PostgreSQL et du rollback, puis recherchez dans le dépôt les utilisations de MongoDB room/session/attempt/solve, les flags dual-write et shadow-read, ainsi que les métriques propres à la migration. Exécutez les tests end-to-end des salles normales et de compétition et consultez la documentation relative au backup, au restore, au développement, au deployment et à l’architecture ; c’est terminé lorsque les recherches de chemins supprimés et l’instrumentation à l’exécution sont propres, que le nettoyage peut être exécuté en dry-run et est idempotent, et que les tests indiqués passent.

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