Add a feature-flagged PostgreSQL solve-history read API

Goal

Expose durable per-user solve history from PostgreSQL only after the Room/RaceSession aggregate is authoritative. Do not build this API around the legacy room-embedded attempt model.

Read contract

• Require the authenticated user.
• Return cursor-paginated completed solves with stable solve ID, event, time, +2/DNF penalties, scramble, Room/RaceSession reference, and timestamps.
• Authorize private, hidden, expired, and deleted-room history server-side. Do not return passwords, access codes, room membership, or moderation data.
• Query the canonical PostgreSQL Solve → Attempt → RaceSession → Room relationship; Solve.room_id is only a temporary migration compatibility field and must not define API semantics.
• Use a session-aware deterministic index and cursor compatible with the final schema.
• Gate the client endpoint behind configuration and retain an explicit disable path, not a MongoDB fallback after aggregate cutover.
• Instrument latency and error/disable behavior without logging solve data or identity.

Acceptance criteria

• The API is authenticated, cursor-paginated, and stable across concurrent new solves.
• It returns the final Room/RaceSession-shaped representation and correct penalties/scrambles.
• Private-room, hidden/deleted-room, empty-history, disabled, and pagination authorization tests pass.
• Disabled PostgreSQL behavior is explicit and does not read MongoDB room/result state.
• Client history and csTimer-export consumers are documented against the final contract.

Dependencies

• #199, including #200, #203, #204, #175, and #202.
• Stable production rollout from #176 and settled room ownership/admin semantics from PR #195.
• The PostgreSQL aggregate cutover and reconciliation must complete before implementation begins.

Unlocks

• #160
• #161
• #163

依存関係 #199 と、リンクされている #200、#203、#204、#175、#202 から始め、#176 と PR #195 に記載された PostgreSQL Room/RaceSession aggregate と rollout の前提条件を確認します。private/hidden/deleted-room、empty-history、disabled、pagination について提示されている認可テストを最初の検証ポイントとして使用します。完了とは、認証済み cursor API と文書化された client/csTimer contract が、MongoDB fallback や solve-data logging なしで、すべての acceptance criterion を満たすことです。