fix(db): commit the #542/#543 ledger repairs so cloud has no orphan stamps (#541 follow-up)

Cloud carried 175 migration stamps against 173 files on master. The two extra:

  20260726013256  repair_migration_ledger_542
  20260726015858  repair_migration_ledger_543

Both were applied through the MCP `apply_migration` tool while #542 and #543
were being worked, but neither committed a matching file. Each repair correctly
realigned its own migration's stamp — and then became an orphan itself, because
`apply_migration` stamps a FRESH timestamp rather than the filename. One orphan
traded for another; the ledger never actually converged.

Committing the files is what closes the loop, which is why #541's own repair
shipped as 20260726005843_repair_migration_ledger_541.sql.

The SQL in both files is reproduced verbatim from
`supabase_migrations.schema_migrations.statements` for the corresponding
version; only the explanatory headers were added. Nothing is re-applied to
cloud — the statements have already run there, and this commit exists so the
repo can account for them.

Both are idempotent: on a fresh `supabase db reset` the UPDATEs match nothing,
because the CLI stamps 20260726100000 / 20260726110000 from the filenames in
the first place.

Ledger after this commit: 175 files, 175 stamps, zero pending, zero orphans —
verified by diffing supabase/migrations/ against schema_migrations.

This is the condition `npm run verify:cloud` (#541) reports as "cloud carries no
migration stamp that matches no repo file", and is how it was caught, hours
after that check shipped.

Gates: test:unit 411 passed, typecheck clean, build succeeds.

Refs #540, #541, #542, #543

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HPFyHjqzSR6Ku1gyWjeQie

Author: guillermoscript

supabase/migrations/20260726013256_repair_migration_ledger_542.sql

@@ -0,0 +1,31 @@
+-- Ledger repair for #542, reconstructed to close an orphan stamp (#541 follow-up).
+--
+-- This SQL was applied to cloud on 2026-07-26 through the MCP `apply_migration`
+-- tool while #542 was being worked, but no matching file was committed. The
+-- statement below is reproduced verbatim from
+-- `supabase_migrations.schema_migrations.statements` for version 20260726013256;
+-- only this header has been added.
+--
+-- WHY THE FILE HAS TO EXIST. `apply_migration` stamps a FRESH timestamp instead
+-- of the migration's filename, so #542's repair correctly realigned
+-- `rls_exam_child_tables_tenant_gate` — and then became an orphan stamp itself,
+-- because the repair carried a stamp (20260726013256) that matched no file in
+-- supabase/migrations/. Net effect: one orphan traded for another. Committing
+-- the file is what actually closes the loop, and is why #541's own repair
+-- shipped as 20260726005843_repair_migration_ledger_541.sql.
+--
+-- `npm run verify:cloud` reports exactly this condition ("cloud carries no
+-- migration stamp that matches no repo file"), which is how it was caught.
+--
+-- Idempotent: on a fresh `supabase db reset` the UPDATE matches nothing, because
+-- the CLI stamps 20260726100000 from the filename in the first place. It is a
+-- no-op everywhere except the cloud project it has already run on.
+
+-- The MCP apply_migration stamps a fresh timestamp rather than the repo
+-- filename's, which makes the repo migration look absent from cloud to any
+-- drift check that compares versions (#541). Realign this one row with
+-- supabase/migrations/20260726100000_rls_exam_child_tables_tenant_gate.sql.
+UPDATE supabase_migrations.schema_migrations
+   SET version = '20260726100000'
+ WHERE name = 'rls_exam_child_tables_tenant_gate'
+   AND version = '20260726013216';

supabase/migrations/20260726015858_repair_migration_ledger_543.sql

@@ -0,0 +1,26 @@
+-- Ledger repair for #543, reconstructed to close an orphan stamp (#541 follow-up).
+--
+-- This SQL was applied to cloud on 2026-07-26 through the MCP `apply_migration`
+-- tool while #543 was being worked, but no matching file was committed. The
+-- statement below is reproduced verbatim from
+-- `supabase_migrations.schema_migrations.statements` for version 20260726015858;
+-- only this header has been added.
+--
+-- Same shape as its sibling 20260726013256_repair_migration_ledger_542.sql:
+-- `apply_migration` stamps a FRESH timestamp instead of the migration's
+-- filename, so #543's repair correctly realigned `write_side_entitlement_gates`
+-- and then became an orphan stamp itself (20260726015858 matched no file).
+-- Committing the file is what closes the loop.
+--
+-- Idempotent: on a fresh `supabase db reset` the UPDATE matches nothing, because
+-- the CLI stamps 20260726110000 from the filename in the first place. It is a
+-- no-op everywhere except the cloud project it has already run on.
+
+-- Ledger repair for #543. `apply_migration` stamps a fresh timestamp rather than
+-- the repo filename (see #541), so 20260726110000_write_side_entitlement_gates.sql
+-- landed as version 20260726015553. Realign the version with the file so
+-- repo-vs-ledger diffing stops reporting it as pending.
+UPDATE supabase_migrations.schema_migrations
+SET version = '20260726110000'
+WHERE name = 'write_side_entitlement_gates'
+  AND version = '20260726015553';