顧客APIの整理とセキュアな /me/customer への移行

[reiroop]

解決したい課題

現在の /customers エンドポイント（GET, POST, PATCH）は、ログインセッションに紐づく顧客情報を操作する設計になっていますが、以下の設計上およびセキュリティ上の課題があります。

1. パス定義の曖昧さ: コレクションパスである /customers を、パスパラメータ（例: {customer_id}）なしで「現在のログインセッションのユーザー」に対して暗黙的に流用しているため、REST APIとしての意味が曖昧になっています。
2. 個人情報漏洩（PII Leak）のリスク: 従来の GET /customers（ルックアップAPI）は、クエリパラメータ（traq_id や email）を指定することで特定の顧客を1件取得できる仕様でした。しかし、このAPIは一般ユーザーでも呼び出せるため、他人のIDやアドレスを指定して本名やStripe顧客IDなどの個人情報を盗み見できる脆弱性があります。

---

達成したい要件・仕様設計

上記課題を根本的に解決し、極限までシンプルかつ安全な設計（Secure by Design）を実現するため、以下の要件を満たすリファクタリングを行います。

1. 従来の /customers パス（GET/POST/PATCH）の完全廃止

• 暗黙のセッション依存やセキュリティ懸念のある旧エンドポイントはすべて廃止（削除）します。

2. 新規セキュアパス /me/customer の新設

ログインユーザー自身の顧客情報操作に特化した、パラメータを一切持たないセキュアなエンドポイントを新設します。

• GET /me/customer: ログインユーザー自身の顧客情報を取得（未登録時は 404）
• POST /me/customer: ログインユーザー自身の顧客情報を作成（Stripe上の顧客登録）
• PATCH /me/customer: ログインユーザー自身の顧客情報を更新
• タグの整理: ログインユーザー関連のエンドポイントとして /me とまとまりを持たせるため、すべて User タグとしてグループ化します（これに伴い、Customer タグは廃止します）。

3. 検索用ルックアップ機能の廃止

• 会計責任者などが決済情報を確認・管理する /invoices や /checkout/sessions の一覧取得レスポンスには、すでに Customer オブジェクトが丸ごと内包（ネスト）して返却される設計になっています。
• そのため、個別で他人の情報を照会するルックアップAPIは実質不要であり、情報漏洩リスクを完全に排除するため検索用API（例: /customers/lookup）は新設せず廃止とします。