fix(db): make expand-only migration deferral honest in schema.ts

schema.ts still declared .references(() => folder.id) on
workflow.folderId/workspaceFiles.folderId even though the migration
defers adding that FK to a future contract migration (blue/green
safety). That left the drizzle snapshot recording the FK as already
present, so a future `drizzle-kit generate` would never emit the
contract migration to actually add it back.

Drop the .references() from both columns (plain text columns until
the contract phase re-adds them) and regenerate 0258 from scratch so
the snapshot matches the real post-migration schema.

Author: waleedlatif1

…s/db/migrations/0258_lyrical_flatman.sql …ages/db/migrations/0258_lumpy_terrax.sqlpackages/db/migrations/0258_lyrical_flatman.sql renamed to packages/db/migrations/0258_lumpy_terrax.sql packages/db/migrations/0258_lyrical_flatman.sql renamed to packages/db/migrations/0258_lumpy_terrax.sql

@@ -22,8 +22,18 @@ CREATE TABLE "pinned_item" (
 	"pinned_at" timestamp DEFAULT now() NOT NULL
 );
 --> statement-breakpoint
+-- Drops the FK's old target only, no replacement added here — this strictly loosens
+-- the column (removes a check, adds none), so it cannot reject any write that used to
+-- succeed. Adding a `folder`-targeted FK in this same migration would reject a
+-- still-running old-code pod (blue/green cutover) writing a workflow_folder-only id;
+-- that FK is deferred to a follow-up migration once old code is fully drained
+-- (contract-pending marker on workflow.folderId in schema.ts). App-layer validation
+-- already independently enforces the invariant on both old and new code paths.
+-- migration-safe: strictly loosens the column, no cross-deploy write can be rejected by removing this constraint; see contract-pending marker on workflow.folderId in schema.ts
 ALTER TABLE "workflow" DROP CONSTRAINT "workflow_folder_id_workflow_folder_id_fk";
 --> statement-breakpoint
+-- Same reasoning as the workflow.folder_id drop above.
+-- migration-safe: strictly loosens the column, no cross-deploy write can be rejected by removing this constraint; see contract-pending marker on workspaceFiles.folderId in schema.ts
 ALTER TABLE "workspace_files" DROP CONSTRAINT "workspace_files_folder_id_workspace_file_folders_id_fk";
 --> statement-breakpoint
 ALTER TABLE "knowledge_base" ADD COLUMN "folder_id" text;--> statement-breakpoint
@@ -117,9 +127,24 @@ FROM (
 	FROM "workspace_file_folders"
 ) "ranked_workspace_file_folders";
 --> statement-breakpoint
-ALTER TABLE "knowledge_base" ADD CONSTRAINT "knowledge_base_folder_id_folder_id_fk" FOREIGN KEY ("folder_id") REFERENCES "public"."folder"("id") ON DELETE set null ON UPDATE no action;--> statement-breakpoint
-ALTER TABLE "user_table_definitions" ADD CONSTRAINT "user_table_definitions_folder_id_folder_id_fk" FOREIGN KEY ("folder_id") REFERENCES "public"."folder"("id") ON DELETE set null ON UPDATE no action;--> statement-breakpoint
-ALTER TABLE "workflow" ADD CONSTRAINT "workflow_folder_id_folder_id_fk" FOREIGN KEY ("folder_id") REFERENCES "public"."folder"("id") ON DELETE set null ON UPDATE no action;--> statement-breakpoint
-ALTER TABLE "workspace_files" ADD CONSTRAINT "workspace_files_folder_id_folder_id_fk" FOREIGN KEY ("folder_id") REFERENCES "public"."folder"("id") ON DELETE set null ON UPDATE no action;--> statement-breakpoint
-CREATE INDEX "kb_folder_id_idx" ON "knowledge_base" USING btree ("folder_id");--> statement-breakpoint
-CREATE INDEX "user_table_def_folder_id_idx" ON "user_table_definitions" USING btree ("folder_id");
+-- knowledge_base.folder_id / user_table_definitions.folder_id are brand-new columns added
+-- earlier in this same migration (all rows NULL) -- no old or new code reads/writes them
+-- yet, so adding their FK here (unlike workflow/workspace_files above) has zero cross-deploy
+-- write-compatibility risk. NOT VALID + an immediate VALIDATE still avoids the full-table
+-- lock a plain ADD CONSTRAINT would take (validating an all-NULL column is instant either
+-- way, but this keeps the pattern uniform and matches this repo's established precedent,
+-- e.g. migrations/0243_kb_workspace_cascade.sql).
+ALTER TABLE "knowledge_base" ADD CONSTRAINT "knowledge_base_folder_id_folder_id_fk" FOREIGN KEY ("folder_id") REFERENCES "public"."folder"("id") ON DELETE set null ON UPDATE no action NOT VALID;--> statement-breakpoint
+ALTER TABLE "knowledge_base" VALIDATE CONSTRAINT "knowledge_base_folder_id_folder_id_fk";--> statement-breakpoint
+ALTER TABLE "user_table_definitions" ADD CONSTRAINT "user_table_definitions_folder_id_folder_id_fk" FOREIGN KEY ("folder_id") REFERENCES "public"."folder"("id") ON DELETE set null ON UPDATE no action NOT VALID;--> statement-breakpoint
+ALTER TABLE "user_table_definitions" VALIDATE CONSTRAINT "user_table_definitions_folder_id_folder_id_fk";--> statement-breakpoint
+-- knowledge_base/user_table_definitions are existing tables: build these indexes
+-- CONCURRENTLY so the build never write-locks the relation (runner convention -- plain
+-- CREATE INDEX takes ACCESS EXCLUSIVE; see packages/db/scripts/migrate.ts). This must be
+-- the last statement group in the file -- CONCURRENTLY cannot run inside the migration
+-- transaction, so everything after the COMMIT below runs outside it.
+COMMIT;--> statement-breakpoint
+SET lock_timeout = 0;--> statement-breakpoint
+CREATE INDEX CONCURRENTLY IF NOT EXISTS "kb_folder_id_idx" ON "knowledge_base" USING btree ("folder_id");--> statement-breakpoint
+CREATE INDEX CONCURRENTLY IF NOT EXISTS "user_table_def_folder_id_idx" ON "user_table_definitions" USING btree ("folder_id");--> statement-breakpoint
+SET lock_timeout = '5s';