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.

まず、PostgreSQL の cutover と rollback の観測ウィンドウを確認し、次にリポジトリ内で MongoDB room/session/attempt/solve の使用箇所、dual-write および shadow-read のフラグ、移行専用のメトリクスを検索します。通常の room とコンペティション room の end-to-end テストを実行し、backup、restore、開発、deployment、アーキテクチャのドキュメントを確認します。完了とは、削除対象パスの検索結果と実行時インストルメンテーションに問題がなく、クリーンアップを dry-run で実行できて冪等であり、列挙されたテストに合格することです。

索引モデルが issue の本文から書いたものです。