Database migration

# Migration: [what changes] ## Intent[Change the schema how] so that [the feature or fix it enables]. ## Context- Database: [Postgres version, hosting]- Tables: [`public.table`], about [row count] rows- Migrations live in [`supabase/migrations/`]; rollbacks in [`supabase/rollbacks/`] ## What to do1. Add [column / table / index] with [type, default, constraint].2. Backfill [what] in batches of [n].3. Update [policies, functions or views] that read it.4. Write a rollback that [keeps or drops what]. ## Constraints- No downtime and no long locks on [table].- Existing rows keep their meaning; nothing is deleted.- Row-level security stays at least as strict as today. ## Out of scope- [Application changes that use the new column] ## Open questions- [How many rows are affected, and may the table be locked while it runs? Remove it when settled.] ## Acceptance checks- The migration applies to an empty database and to a copy of production- The rollback restores the previous schema without losing data- Existing queries of [table] return the same results- A user without access still cannot read [table]