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.

Beginnen Sie damit, das Beobachtungsfenster für die PostgreSQL-Umstellung und das Rollback zu bestätigen, und durchsuchen Sie dann das Repository nach der Verwendung von MongoDB room/session/attempt/solve, nach dual-write- und shadow-read-Flags sowie nach ausschließlich migrationsbezogenen Metriken. Führen Sie die End-to-End-Tests für normale und Wettbewerbsräume aus und prüfen Sie die Dokumentation zu Backup, Restore, Entwicklung, Deployment und Architektur; abgeschlossen bedeutet, dass die Suchen nach entfernten Pfaden und die Laufzeitinstrumentierung sauber sind, die Bereinigung im Dry-Run ausführbar und idempotent ist und die aufgeführten Tests bestehen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.