[P1][Database] Drizzle migration historyを再構築し、安全な前進適用を保証する

[yufoxda]

問題

share/drizzle の移行履歴がDrizzle migratorで読み込めず、現行スキーマの再現にも使用できない。解消まで、DBスキーマ変更を含むリリースを停止する。

確認済み事実

• meta/_journal.json は 0003_add_auth_trigger を参照するが、対応SQLが存在しない。
• 0006_event_messages.sql と 0007_soft_rls.sql は存在するがjournalに登録されていない。
• readMigrationFiles() は No file ... 0003_add_auth_trigger.sql found で停止する。
• drizzle-kit check はこの状態でも Everything's fine と終了し、欠損を検出できない。
• 0000_great_edwin_jarvis.sql のDDLは全体がコメントアウトされ、空DBを再現できない。
• 最終snapshotは旧users/categories/roles等を表す一方、現行schemaはBetter Auth tablesとevent_messagesを表し、履歴が一致しない。
• CIにmanifest整合性、空DB replay、schema drift検査がない。

本番確認が必要な事項

• 実際に適用済みのSQLと順序
• drizzle.__drizzle_migrations とSupabase側ledger
• 0006/0007の手動適用有無
• Better Auth移行時のデータ処理
• handle_new_user trigger、app_rls role、RLS policyの実状態

実施方針

1. 本番変更前にschema-only dump、migration ledger、件数・制約・policy・role・triggerを読み取り専用で収集する。
2. バックアップ、復元手順、rollback条件を決める。
3. 証拠に基づく履歴再構築か、現行本番からのcanonical baseline化かをADRで決定する。
4. migration生成・検査・適用を一つの入口へ統一する。
5. manifest検査、空DB replay、既存DBからの前進適用をCI化する。
6. 本番適用runbookを作成する。

禁止事項

• 調査前に0003を推測で作らない。
• 0006/0007をjournalへ機械的に追記しない。
• 適用済みSQL/hash/timestampやmigration ledgerを証拠なく変更しない。
• 本番でdrizzle-kit push、無条件DROPを実行しない。

受入条件

• journal tagとSQLが1対1、idxとsnapshot chainが連続する
• 空の代表Postgres/Supabaseへmigrationを最初から適用できる
• tables/columns/PK/FK/indexがschema.tsと一致する
• role/grant/RLS policy/triggerをcatalog assertionで検証する
• 本番sanitized cloneへデータ損失なしで前進適用できる
• CIがjournal欠損、journal外SQL、snapshot破損、replay失敗、schema driftを検出する
• backup・適用・照合・rollbackを含むrunbookがある