セッション・管理者依存エンドポイントの契約とバックエンドを実装する

背景

以下のエンドポイントは、現在のセッション(traQ ID)や管理者情報に依存するため、認証サブシステム(#16)と、traQ ID ↔ Stripe Customer のマッピングが用意できてから、契約とバックエンドを併せて実装する。

マッピングは自前 DB で持つ方針:

• DB に traq_id / Stripe Customer ID / メールアドレスの sha256 ハッシュを保持する。メールアドレスは個人情報のため生では持たず(Stripe 側が保持)、ハッシュはメールアドレスから既存アカウントを検索する用途(セッションが無い再入部時などの本人特定。#22 参照)に用いる。
• 管理者情報も DB で持つ(is_admin は DB 参照)。
• traQ ID はリクエストごとに NeoShowcase プロキシの X-Forwarded-User ヘッダ(#16)から取得する。
• API 出力で traq_id を返す場合は、Stripe metadata ではなく DB 逆引き(Stripe Customer ID → traq_id)で解決する。

対象エンドポイント

• GET /me — セッション情報(email / traq_id / is_admin / customer_id)
• GET /me/customer — 現在のユーザーの Stripe Customer 取得
• POST /me/customer — Customer 作成(DB に traq_id と対応付けて登録)
• PATCH /me/customer — Customer 更新
• POST /me/invoices — 現在のユーザー向け Invoice 作成
• GET /admin — 管理者一覧

やること

• DB スキーマ: traq_id / Stripe Customer ID / メールの sha256 ハッシュ、管理者情報
• 上記エンドポイントの oRPC 契約(入出力スキーマ)を定義
• Stripe SDK + セッションコンテキスト + DB でバックエンドを実装(traq_id は DB 逆引きで解決)
• 認可(#15)を適用(ユーザー系はセッション必須、admin は DB の管理者情報で判定)

スコープ外/関連

• 認証サブシステムは #16、認可・レート制限は #15。
• セッション不要な Stripe カタログ/請求の管理系(CRUD)エンドポイントは、本 issue に先行して実装する。本 issue はその後段として、セッション・管理者依存のエンドポイントを担う。
• 先行実装で Stripe metadata から traq_id を返している箇所は、本 issue で DB 逆引き(Stripe Customer ID → traq_id)に置き換える。

Start by reading authentication issue #16, authorization issue #15, and the existing session-free Stripe catalog and billing endpoints. Trace the DB schema and oRPC contract conventions before covering GET /me, customer operations, invoice creation, and GET /admin. Done means the schemas, mappings, session checks, and admin checks work together for all listed endpoints.