Backfill MongoDB data into PostgreSQL and verify ongoing parity

Part of #199.

## Goal

Turn PostgreSQL dual writes into a trustworthy migration target by copying historical MongoDB data and continuously checking parity.

For the competition-room foundation, this backfill must target the new Room/RaceSession model rather than preserving the current assumption that a room is itself one racing session.

## RaceSession mapping

- Convert each existing MongoDB room into one PostgreSQL Room plus one RaceSession for its current event.
- Attach every embedded attempt to that RaceSession while preserving deterministic attempt and solve IDs.
- Populate session participant state according to the approved domain contract.
- Preserve room identity, access code, ownership, privacy, timestamps, and deletion/expiration state.
- Make the mapping explicit and repeatable; do not attempt to infer event sessions whose attempts were already deleted by the legacy event-change behavior.
- Verify concurrent live writes are neither lost nor duplicated during the backfill.

## Acceptance criteria

- [ ] Implement an idempotent, resumable backfill for users/preferences, rooms, race sessions, participant state, attempts, durable solve results, and sanitized metrics.
- [ ] Support dry-run, bounded batches, progress checkpoints, and safe retries.
- [ ] Do not copy OAuth access tokens or prohibited metric fields.
- [ ] Produce reconciliation output for record counts, missing identifiers, duplicate identifiers, room/session relationships, penalty fields, and representative aggregates.
- [ ] Verify every attempt belongs to the expected RaceSession and every RaceSession belongs to the expected Room.
- [ ] Verify writes arriving during the backfill are not lost or duplicated.
- [ ] Document operational invocation, expected runtime/load, alerts, failure recovery, and how to rerun only failed ranges.
- [ ] Add focused tests for deterministic IDs, cursor boundaries, retry behavior, session mapping, and reconciliation failures.

## Dependencies

- Stable production dual writes from PR #171, deployed through #176.
- The Room/RaceSession domain contract and expansion schema from #200 and #203.
- The schema and migration history must remain compatible with rollback requirements.

## Unlocks

- #202
- #174
- #160

Start with the Room/RaceSession domain contract and expansion schema from #200 and #203, then review the dual-write and deployment context in PR #171 and #176 plus the schema migration history. Trace the required mappings and rollback constraints before defining the resumable backfill. Done means reconciliation, retry and concurrency checks, focused tests, and operational documentation cover the listed acceptance criteria.

Vom Indexierungsmodell aus dem Issue-Text verfasst.