fix: ffmpeg-Binary im Container fehlte (ENOENT bei jedem Video-Upload)

Live-Log zeigte: spawn .../ffmpeg-static/ffmpeg ENOENT bei jedem
Transcode-Versuch, unabhaengig vom Videoformat (.mov war nur zufaellig
der zuletzt getestete Fall). Die ffmpeg-static-Binary aus der
migrator-Docker-Stage kam nicht zuverlaessig im finalen Image an.

Root-Fix: ffmpeg jetzt per "apk add ffmpeg" als System-Paket in der
runner-Stage installiert - liegt fest unter /usr/bin auf PATH,
unabhaengig von jeder Node/pnpm-Kopiermechanik. lib/video-transcode.ts
versucht zuerst "ffmpeg" ueber PATH und faellt nur bei ENOENT (kein
System-ffmpeg vorhanden, typischerweise lokale Windows-/Mac-Entwicklung)
auf die per npm mitgelieferte ffmpeg-static-Binary zurueck, damit
"npm run dev" weiterhin ohne manuelle Einrichtung funktioniert. Beide
Pfade lokal gegen ein synthetisches Testvideo verifiziert.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

Dockerfile

@@ -27,25 +27,13 @@ ENV DATABASE_URL="postgresql://placeholder:placeholder@localhost:5432/placeholde
 # Datenbanken wechseln kann, siehe lib/prisma.ts.
 RUN pnpm build
 
-# --- Migrator-Tools + Laufzeit-Zusatzpakete --------------------------------
+# --- Migrator-Tools -----------------------------------------------------
 # Eigenstaendiger, schlanker node_modules-Baum nur mit Prisma-CLI, tsx und
 # den paar Laufzeit-Paketen, die prisma/seed.ts importiert — NICHT
 # next/react/sharp/stripe/alle devDependencies, die der volle builder-Stage
 # oben mitbringt. Wird unten in die runner-Stage kopiert, damit die App sich
 # beim Start selbst migrieren/seeden kann (kein separates Migrations-Image/
 # kein Kubernetes-Job mehr noetig).
-#
-# ffmpeg-static (Video-Transcoding, siehe lib/video-transcode.ts) landet
-# bewusst HIER statt per Next.js' automatischer Standalone-Output-Tracing
-# aus der builder-Stage: dessen heruntergeladene ffmpeg-Binary liegt im
-# pnpm-Store hinter einem Symlink, den Next.js' Tracer (anders als bei
-# sharp, dafuer gibt es eine Sonderbehandlung) nicht zuverlaessig erkennt,
-# UND ein direktes COPY einzelner Pakete aus dem pnpm-Store der
-# builder-Stage wuerde denselben Symlink lediglich unaufgeloest (und damit
-# kaputt) in die runner-Stage kopieren. Diese Stage installiert stattdessen
-# jedes benoetigte Laufzeitpaket ueber ein eigenes, in sich geschlossenes
-# "pnpm add" neu — genau das Muster, das fuer Prisma/tsx hier bereits
-# funktioniert.
 FROM base AS migrator
 # pnpm-workspace.yaml zuerst kopieren: pnpm v11 blockt Postinstall-Skripte
 # (u.a. @prisma/engines, laedt die Schema-Engine-Binary fuer "migrate
@@ -62,12 +50,19 @@ COPY pnpm-workspace.yaml ./
 RUN pnpm add --save-prod \
   prisma@^7.9.1 tsx@^4 bcryptjs@^3.0.3 dotenv@^17.4.2 \
   @prisma/client@^7.9.1 @prisma/adapter-pg@^7.9.1 \
-  @prisma/adapter-mariadb@^7.9.1 mariadb@^3.5.3 \
-  ffmpeg-static@^5.3.0
+  @prisma/adapter-mariadb@^7.9.1 mariadb@^3.5.3
 
 # --- Runtime --------------------------------------------------------------
 FROM base AS runner
 ENV NODE_ENV=production
+# System-ffmpeg statt des npm-Pakets ffmpeg-static (lib/video-transcode.ts
+# nutzt es lokal per "npm run dev" trotzdem als Fallback, siehe dort):
+# ffmpeg-static laedt seine Binary in den pnpm-Store, dessen Pfad ueber
+# mehrere Docker-Build-Stages hinweg (migrator -> runner) per COPY nicht
+# zuverlaessig ankam (spawn ... ffmpeg ENOENT im Betrieb beobachtet). Ein
+# per apk installiertes System-Paket liegt dagegen fest unter /usr/bin auf
+# PATH, unabhaengig von jeder Node/pnpm-Verzeichnisstruktur.
+RUN apk add --no-cache ffmpeg
 RUN addgroup --system --gid 1001 nodejs \
   && adduser --system --uid 1001 nextjs