fix(migration): create replacement index before dropping the unique one

20260605122718_drop_wpo dropped uniq_wpo_user_date (the sole index covering the user_id FK) BEFORE creating idx_wpo_user_date, which MySQL rejects on a fresh apply ('Cannot drop index ... needed in a foreign key constraint'). Reordered so the replacement index exists first. This migration is not yet applied on production, so editing it is safe; the resulting index state is unchanged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

prisma/migrations/20260605122718_drop_wpo_unique_constraint/migration.sql

@@ -9,12 +9,18 @@
 -- The original index was created in
 -- 20260605120000_add_work_plan/migration.sql as `uniq_wpo_user_date`.
 
-DROP INDEX `uniq_wpo_user_date` ON `work_plan_overrides`;
+-- IMPORTANT ordering: `uniq_wpo_user_date` is the only index covering the
+-- `user_id` foreign key, and MySQL refuses to drop an index still needed by a
+-- FK. So we CREATE the replacement non-unique index FIRST (giving the FK
+-- another covering index), THEN drop the unique one. The reverse order fails
+-- with "Cannot drop index ... needed in a foreign key constraint" on a fresh
+-- apply.
 
 -- Add a non-unique index for the (user_id, shift_date) lookup used by
 -- createOverride's "is there an active override for this user-day?" query
 -- and by resolveCell / resolveGrid. This is a plain index, not a unique
 -- one — multiple rows (active and soft-deleted) can share the same
 -- (user_id, shift_date) pair.
-
 CREATE INDEX `idx_wpo_user_date` ON `work_plan_overrides`(`user_id`, `shift_date`);
+
+DROP INDEX `uniq_wpo_user_date` ON `work_plan_overrides`;