入出金の統合台帳 ledger.list を DB ベースで実装する

背景

現状はソース別エンドポイント(invoices.list / checkout.sessions.list)がそれぞれ独立した Stripe カーソルを返す。Stripe カーソルはソースをまたいで統合できないため、日時順に並べた単一の一覧をクライアント側で正しくページネーションできない。全件取得してマージすれば作れるが、それではページネーションの意味が無くなる。

やること

• webhook(#17)で各支払いを DB に記録し、統合台帳を DB から取得する。これで Stripe カーソルを統合できない問題を回避する。
• ledger.list は Checkin 独自のプロバイダ非依存な entry 形式(amount / direction / occurred_at / source / status 等、Stripe 語彙に依存しない)で返す。決済プロバイダを抽象化する境界はこの entry 形式に置く。ソース別の一覧(invoices.list 等)は Stripe リソースをほぼそのまま写すだけなので、そこを抽象化しても利点は無い。
• ページネーションは occurred_at を基準にした独自カーソルで行う。一覧のレスポンス形式 { data, next_cursor } は既存のものをそのまま使える。
• 支払者(traq_id / 氏名)を customer_id → DB 逆引きで entry に付与する(会計が「誰の支払いか」を判別できるように)。

関連

• #17(webhook を受けて支払いを DB に記録する仕組み)が前提。
• 現状の invoices.list / checkout.sessions.list は当面は管理用の基本エンドポイントとして残す。台帳が用意できたら、管理者が詳細を確認する用途に限定する(降格)か内部化するかを再検討する。

Start by reading the webhook work in issue #17 and the existing invoices.list and checkout.sessions.list endpoints. Define how ledger.list stores and returns provider-independent entries, including customer lookup and occurred_at-based cursors. Done means the database-backed response uses { data, next_cursor } and supports correct unified pagination.