fix(s3): add upgrade migration for composite (drawingId, fileId) PK

Prior versions of this branch shipped the new S3File composite primary
key by editing the original `20260408060000_add_s3_files` migration in
place. That works for fresh deployments but is invisible to any
deployment that already applied the original `id`-only PK migration —
Prisma decides what to apply by migration name, so the new shape never
reaches the database and runtime upserts crash with
"The column `drawingId` does not exist in the current database."

Restore the original migration to its pre-bundle shape and add a
follow-up migration that drops + recreates S3File with the new shape.
Both fresh and upgrade paths converge on the composite PK. Existing
S3 objects are untouched; public-bucket deployments are unaffected.
Private-bucket deployments will see /api/files/:drawingId/:fileId 404
for legacy rows until those drawings are re-saved (the save flow
upserts on every base64 dataURL); operators with valuable legacy rows
can rebuild manually before deploying.

Change-Id: I9c06c7a46247050521a1d5013ec37eeebeb86247
Co-developed-by: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: OhYee

backend/prisma/migrations/20260408060000_add_s3_files/migration.sql

@@ -1,17 +1,10 @@
 -- Track S3-uploaded image files for presigned download URL generation.
--- The primary key is composite (drawingId, fileId): Excalidraw fileIds
--- are content hashes that repeat across drawings, so a global PK on
--- fileId alone would let a second upload silently overwrite the first
--- and let cleanup of one drawing trash an object the other still needs.
 CREATE TABLE "S3File" (
-    "drawingId" TEXT NOT NULL,
-    "fileId"    TEXT NOT NULL,
+    "id"        TEXT NOT NULL PRIMARY KEY,
     "userId"    TEXT NOT NULL,
     "s3Key"     TEXT NOT NULL,
     "mimeType"  TEXT NOT NULL,
-    "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
-    PRIMARY KEY ("drawingId", "fileId")
+    "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
 );
 
 CREATE INDEX "S3File_userId_idx" ON "S3File"("userId");
-CREATE INDEX "S3File_drawingId_idx" ON "S3File"("drawingId");

backend/prisma/migrations/20260506130000_s3file_composite_pk/migration.sql

@@ -0,0 +1,32 @@
+-- Migrate S3File from a single-column `id` (= fileId) primary key to a
+-- composite (drawingId, fileId) primary key.
+--
+-- Why: Excalidraw fileIds are content hashes that legitimately repeat
+-- across drawings; a global PK on fileId alone meant the second upload
+-- of the same image silently overwrote the first row's s3Key, and any
+-- prefix-scoped cleanup deleted objects the sibling drawing still
+-- needed.
+--
+-- This migration drops the existing S3File rows and recreates the
+-- table with the new shape. Public-bucket deployments are unaffected
+-- (image dataURLs already encode the bucket URL directly). Private-
+-- bucket deployments will see /api/files/:drawingId/:fileId 404 for
+-- pre-existing images until each affected drawing is re-saved (the
+-- save flow upserts a fresh row per (drawingId, fileId) only when it
+-- detects new base64 dataURLs, so legacy rows must be rebuilt by hand
+-- if needed). S3 objects themselves are untouched.
+
+DROP TABLE IF EXISTS "S3File";
+
+CREATE TABLE "S3File" (
+    "drawingId" TEXT NOT NULL,
+    "fileId"    TEXT NOT NULL,
+    "userId"    TEXT NOT NULL,
+    "s3Key"     TEXT NOT NULL,
+    "mimeType"  TEXT NOT NULL,
+    "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    PRIMARY KEY ("drawingId", "fileId")
+);
+
+CREATE INDEX "S3File_userId_idx" ON "S3File"("userId");
+CREATE INDEX "S3File_drawingId_idx" ON "S3File"("drawingId");