fix(db): drop FK on agent_task_queue.initiator_user_id (MUL-2645) (#3959)

The initiator_user_id column (added in 117) carried a foreign key to the
"user" table. Adding that FK also locks the hot "user" table at migration
time, which made the ALTER time out on a busy production deploy. The
column only feeds a best-effort name/email lookup at claim time (a stale
id just yields no `## Task Initiator` section), so referential integrity
is not load-bearing.

- Edit 117 to add a plain `UUID` column (no FK). The original timed-out
  deploy never recorded 117, so its retry now runs the FK-free version.
- Add 118 to `DROP CONSTRAINT IF EXISTS` for environments that already
  applied the constraint-bearing 117 (they skip the edited 117 by
  version). All environments converge to a plain, FK-free column.

No code/codegen change: dropping the FK does not affect the Go column
type, so sqlc output is unchanged. Verified locally: 118 drops the FK and
keeps the column; sqlc regen produces no diff; build/vet/tests pass.

Co-authored-by: J <j@multica.ai>
Co-authored-by: multica-agent <github@multica.ai>

server/migrations/117_agent_task_queue_initiator_user_id.up.sql

@@ -8,5 +8,12 @@
 -- NULL for non-chat tasks and for chat tasks queued before this column existed;
 -- the brief simply omits the `## Task Initiator` section in that case. See
 -- MUL-2645.
+--
+-- Plain UUID, no FK to "user": adding a foreign key here also takes a lock on
+-- the (hot) "user" table at migration time, which made this ALTER time out on a
+-- busy production deploy. The column only feeds a best-effort name/email lookup
+-- at claim time (a stale id just yields no initiator section), so referential
+-- integrity is not load-bearing. Migration 118 drops the FK on environments
+-- that already applied the original constraint-bearing version of this file.
 ALTER TABLE agent_task_queue
-    ADD COLUMN initiator_user_id UUID REFERENCES "user"(id) ON DELETE SET NULL;
+    ADD COLUMN initiator_user_id UUID;

server/migrations/118_agent_task_queue_initiator_user_id_drop_fk.down.sql

@@ -0,0 +1,7 @@
+-- Intentionally empty. The up is a convergence step ("ensure no FK on
+-- initiator_user_id") whose effect is conditional (DROP CONSTRAINT IF EXISTS),
+-- so it has no single inverse: on a database first migrated with the FK-free
+-- 117 there was never a constraint to restore, and re-adding the FK on rollback
+-- would reintroduce the exact lock-on-"user" timeout this migration removed.
+-- The FK is non-essential, so leaving the column FK-less on rollback is correct.
+-- Full rollback drops the column via 117's down migration.

server/migrations/118_agent_task_queue_initiator_user_id_drop_fk.up.sql

@@ -0,0 +1,13 @@
+-- Converge environments that already applied the original constraint-bearing
+-- version of migration 117 (which added `initiator_user_id` with a foreign key
+-- to "user"). Those environments skip the now-edited 117 by version, so the FK
+-- still exists there; this drops it so every environment ends up with a plain
+-- `initiator_user_id` column and no FK.
+--
+-- The FK to the hot "user" table is what made 117 time out on a busy deploy, and
+-- the column only feeds a best-effort name/email lookup at claim time, so the
+-- constraint is not needed. DROP CONSTRAINT only touches catalog metadata (a
+-- brief lock on agent_task_queue, no table scan, no lock on "user"). IF EXISTS
+-- makes this a no-op where 117 already ran in its FK-free form. See MUL-2645.
+ALTER TABLE agent_task_queue
+    DROP CONSTRAINT IF EXISTS agent_task_queue_initiator_user_id_fkey;