fix(db): stop the re-root dedupe renaming personal workflows

workflow.workspace_id is nullable, and NULL is treated as EQUAL by PARTITION BY
but UNKNOWN by the = in base_taken. So for personal workflows rn incremented
across the group while no collision was ever detected: the dedupe could only
fire spuriously, renaming a user-visible workflow that needed no rename, since
the unique index treats NULL workspace_id rows as distinct anyway. The file
block already carried the equivalent guard.

Also gives step 1's inserts ON CONFLICT (id) DO NOTHING. It restates the
stranded guard, closing the window between that read's snapshot and the index
check — an operational re-run of 0274, or a live pod, committing into folder
mid-statement would otherwise raise 23505, and migrate.ts retries only 55P03.
0272 and 0274 were already written this way; step 1 was the exception.

Corrects three comments that claimed more than the code delivers: the header's
'no legacy folder is lost' (an id already present under another resource_type
cannot be rescued), the reachability note (a cycle among stranded rows survives
a per-row parent check), and a note made stale by the ON CONFLICT above.

Author: waleedlatif1

packages/db/migrations/0276_drop_legacy_folder_tables.sql

@@ -2,7 +2,11 @@
 -- keys and drop the two legacy folder tables.
 --
 -- Ordering is deliberate and each step depends on the one before it:
---   1. final insert-only reconcile, so no legacy folder is lost by the DROP;
+--   1. final insert-only reconcile, so no legacy folder is lost by the DROP — with one
+--      inherent exception: a legacy id already present in `folder` under a DIFFERENT
+--      resource_type cannot be inserted (the primary key is taken) and is dropped. That needs
+--      an id collision across two tables whose ids were preserved from disjoint sources, so it
+--      is not reachable in practice;
 --   2. re-root any `folder_id` that still does not resolve, so the FK can be validated;
 --   3. adopt the FKs the expand migration deliberately left off;
 --   4. drop the legacy tables.
@@ -44,9 +48,10 @@ BEGIN
 	END IF;
 
 	INSERT INTO "folder" (id, resource_type, name, user_id, workspace_id, parent_id, locked, sort_order, created_at, updated_at, deleted_at)
-	-- Keyed on `id` ALONE, matching the primary key this guard protects. Narrowing it by
-	-- resource_type would classify an id already present under a different type as stranded and
-	-- then die on folder_pkey, since there is no ON CONFLICT here.
+	-- Keyed on `id` ALONE, matching the primary key it protects. Narrowing it by resource_type
+	-- would classify an id already present under a DIFFERENT type as stranded; the ON CONFLICT
+	-- below would then silently skip it rather than rescue it, so keeping the guard aligned with
+	-- the constraint is what makes the two agree.
 	WITH stranded AS (
 		SELECT l.id, l.name, l.user_id, l.workspace_id, l.parent_id, l.locked, l.sort_order,
 			l.created_at, l.updated_at, l.archived_at AS deleted_at
@@ -67,6 +72,12 @@ BEGIN
 	--
 	-- Anything else re-roots to the workspace root: losing one level of nesting beats losing the
 	-- folder and stranding every workflow inside it.
+	--
+	-- LIMITATION: this is a per-row check, so a CYCLE among stranded rows (a→b→a) survives it —
+	-- every row's parent exists, is same-workspace, and is active. Such rows land in `folder`
+	-- unreachable from the root. 0272's backfill has the identical hole, so this is not a
+	-- regression, and the client tolerates it (`getFolderPath` and `subtree.ts` both carry cycle
+	-- guards). Breaking cycles needs a recursive walk; it is deliberately not done here.
 	resolved AS (
 		SELECT s.*,
 			CASE
@@ -147,7 +158,12 @@ BEGIN
 		r.user_id, r.workspace_id, r.resolved_parent, r.locked, r.sort_order,
 		r.created_at, r.updated_at, r.deleted_at
 	FROM resolved r
-	LEFT JOIN named n ON n.id = r.id;
+	LEFT JOIN named n ON n.id = r.id
+	-- Matches the `stranded` guard, which already means "no folder row with this id". Restating
+	-- it as ON CONFLICT closes the gap between that read's snapshot and the index check: an
+	-- operational re-run of 0274, or a live pod, committing into `folder` mid-statement would
+	-- otherwise raise 23505 — and migrate.ts retries only 55P03, so that hard-fails the deploy.
+	ON CONFLICT (id) DO NOTHING;
 END $$;
 --> statement-breakpoint
 
@@ -241,7 +257,9 @@ BEGIN
 		r.user_id, r.workspace_id, r.resolved_parent, false, r.sort_order,
 		r.created_at, r.updated_at, r.deleted_at
 	FROM resolved r
-	LEFT JOIN named n ON n.id = r.id;
+	LEFT JOIN named n ON n.id = r.id
+	-- Same rationale as the workflow tree above.
+	ON CONFLICT (id) DO NOTHING;
 END $$;
 --> statement-breakpoint
 
@@ -254,8 +272,16 @@ END $$;
 -- under a suffixed name strictly improves on leaving it invisible.
 DO $$
 BEGIN
+	-- `workspace_id IS NOT NULL` is load-bearing, not defensive. `workflow.workspace_id` is
+	-- nullable (personal workflows), and NULL is treated as EQUAL by `PARTITION BY` but as
+	-- UNKNOWN by the `=` in `base_taken`. Without this guard `rn` increments across every
+	-- personal workflow while no collision is ever detected, so the dedup can ONLY fire
+	-- spuriously — renaming a user-visible workflow that needed no rename, since the unique
+	-- index treats NULL `workspace_id` rows as distinct anyway. The file block below has always
+	-- carried the equivalent guard.
 	WITH dangling AS (
-		SELECT w.id, w.workspace_id, w.name, (w.archived_at IS NULL) AS is_active
+		SELECT w.id, w.workspace_id, w.name,
+			(w.archived_at IS NULL AND w.workspace_id IS NOT NULL) AS is_active
 		FROM "workflow" w
 		WHERE w."folder_id" IS NOT NULL
 			AND NOT EXISTS (SELECT 1 FROM "folder" f WHERE f.id = w."folder_id")