Document why follow-up chat_threads and first_name migrations stay in the chain

Made-with: Cursor

Author: dnywh

supabase/migrations/20260421120000_assign_trimmed_first_name_in_profile_trigger.sql

@@ -1,5 +1,7 @@
--- Environments that already applied 20260420120000 before we assigned back to NEW.first_name
--- get the same trigger body; new installs get it from the original migration, this is idempotent.
+-- Hygiene: 20260420120000 now includes `NEW.first_name := v`, so a fresh `db reset` already
+-- creates the right function. This migration replays the same body for databases that ran an
+-- earlier revision of 20260420120000 (preview/prod). Re-applying on a new install is a no-op
+-- (CREATE OR REPLACE with identical SQL). Safe to keep.
 
 CREATE OR REPLACE FUNCTION public.enforce_profile_first_name_rules() RETURNS trigger
     LANGUAGE plpgsql

supabase/migrations/20260421121500_chat_threads_insert_initiator_only.sql

@@ -2,6 +2,10 @@
 -- Previously, owner_id inserts satisfied (auth.uid() <> initiator_id OR rate_limit) without
 -- evaluating the thread-initiation limit. Initiator-only insert applies that limit to everyone
 -- who can create a thread.
+--
+-- Hygiene: 20260420120000 was updated in Git to the same policy, so a full local `db reset` runs
+-- this twice in spirit (idempotent). This file still matters for any database that had already
+-- applied an older version of 20260420120000 before that edit (e.g. preview/prod). Safe to keep.
 
 DROP POLICY IF EXISTS "Users can create threads they're involved in" ON public.chat_threads;