Persist room solve history and past sessions

Users want to revisit solves and sessions after the live room is gone.

Feedback source:
- Would it be possible to access past solves, like up to 30 days?
- You could make it so you can look at all your past solves.
- Scrambles should remain available after completion while respecting room retention.
- Audio/video feedback also mentioned an option to save the session.

## Current foundation

- PR #171 adds PostgreSQL dual writes for durable solve results while MongoDB remains the live read source.
- PR #140 prevents normal-room TTL deletion by hiding expired rooms, but it predates the current `dev` branch and must be rebased/redesigned.
- #174 defines the first feature-flagged solve-history read API.
- #175 covers the historical backfill and parity checks required before that read path can be trusted.

## Implementation sequence

- [ ] Decide and document retention and privacy behavior for public, private, and deleted/hidden rooms.
- [ ] Rework or split PR #140 on top of the modernized `dev` branch.
- [ ] Deploy and stabilize PostgreSQL dual writes.
- [ ] Complete #175 and verify historical/ongoing parity.
- [ ] Complete #174 with authenticated cursor pagination.
- [ ] Add a profile/session-history UI.
- [ ] Reuse the read API for previous scramble review (#161) and csTimer export (#163).

## Acceptance criteria

- [ ] Completed attempts persist with event, time, penalties, scramble, timestamps, and stable user/session references.
- [ ] Users can browse their history after the live room is hidden or expired.
- [ ] Private-room and deletion/retention expectations are enforced server-side.
- [ ] History pagination is stable and does not expose other users' private data.
- [ ] The migration has a documented disable/rollback path while MongoDB remains the live source of truth.

Inizia esaminando PR #171, PR #140, #174 e #175 per comprendere il lavoro già pianificato su persistenza, retention, read API e parità. Risolvi il comportamento documentato relativo a retention e privacy, quindi segui la sequenza di implementazione fino alla profile/session-history UI. Il lavoro è completato quando i tentativi completati sono consultabili con una paginazione stabile, i dati privati sono protetti e il comportamento del rollback è documentato.

Scritto dal modello di indicizzazione a partire dal testo della issue.