chore(db): align the drop migration filename with the applied prod version (#251)

Applied to prod after #250 deployed; the MCP restamped it as
20260815210532. Rename so supabase db push does not rerun it, and record
that it is already applied.

Author: ralyodio

supabase/migrations/20260815204334_move_backup_pins_to_service_role_table.sql

@@ -67,7 +67,7 @@ ON CONFLICT (user_id) DO NOTHING;
 
 -- --------------------------------------------------------------------------
 -- The `users.backup_pin_hash` column itself is dropped by the NEXT migration,
--- 20260815204400_drop_users_backup_pin_hash.sql. It is deliberately a separate
+-- 20260815210532_drop_users_backup_pin_hash.sql. It is deliberately a separate
 -- step: this migration is additive and safe to apply to a running deployment,
 -- whereas the drop must not land until the application code that stopped
 -- reading that column has shipped.

…815204400_drop_users_backup_pin_hash.sql …815210532_drop_users_backup_pin_hash.sqlsupabase/migrations/20260815204400_drop_users_backup_pin_hash.sql renamed to supabase/migrations/20260815210532_drop_users_backup_pin_hash.sql supabase/migrations/20260815204400_drop_users_backup_pin_hash.sql renamed to supabase/migrations/20260815210532_drop_users_backup_pin_hash.sql

@@ -2,10 +2,6 @@
 -- Advisory: GHSA-jpfm-vrpc-p6rr
 --
 -- Second half of 20260815204334_move_backup_pins_to_service_role_table.sql.
---
--- NOTE: when this is applied via the Supabase MCP, the ledger will restamp it
--- with its own timestamp. Rename this file to match afterwards, or
--- `supabase db push` will rerun it.
 -- That migration created the service-role-only `user_backup_pins` table and
 -- carried across which users have a PIN set. This one removes the column that
 -- every logged-in account could read via `users_select_authenticated`.
@@ -14,6 +10,11 @@
 -- `users.backup_pin_hash` is deployed (src/app/api/auth/backup-pin/route.js).
 -- Applying it against the previous release breaks GET/POST /api/auth/backup-pin.
 --
+-- APPLIED TO PRODUCTION 2026-08-15, after #250 deployed. The ledger restamped it
+-- as version 20260815210532 (the Supabase MCP ignores the filename timestamp and
+-- records its own), and this file was renamed to match so that
+-- `supabase db push` does not rerun it.
+--
 -- The unsalted SHA-256 digests in this column are discarded rather than
 -- migrated: nothing ever verified them server-side, they only backed a boolean,
 -- and their whole problem is that they are trivially reversible.