feat: Hero-Video beim Upload automatisch fuers Web komprimieren (ffmpeg)

Ein direkt von Kamera/Handy hochgeladenes Video (57 MB) lud spuerbar
langsam: keine Kompression, kein Ton entfernt, und ohne "faststart"
musste der Browser oft die gesamte Datei laden, bevor die Wiedergabe
ueberhaupt beginnen konnte.

Neues lib/video-transcode.ts (ffmpeg-static, per pnpm-workspace.yaml
allowBuilds freigegeben) enkodiert jedes hochgeladene Video jetzt zu
einem web-optimierten MP4 neu: Ton entfernt (Hero-Video ist ohnehin
stumm), auf max. 1920px Breite skaliert, CRF 26 mit Bitratendeckel,
"+faststart" fuer sofortigen Wiedergabestart. Nebeneffekt: ein
erfolgreicher Transcode validiert das Video jetzt genauso vollstaendig
wie reencodeImage() das bei Bildern schon tut (nicht mehr nur
Magic-Bytes). ffmpeg-static-Binary wird in der migrator-Docker-Stage
mitinstalliert (Next.js' Standalone-Tracing erkennt den Pfad hinter dem
pnpm-Store-Symlink nicht zuverlaessig), lokal per npm-Postinstall ohne
manuelle Einrichtung.

Getestet mit synthetischem Testvideo: Transcode laeuft durch, Ausgabe
enthaelt keine Audiospur mehr, ist als H.264/MP4 dekodierbar.

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

Dockerfile

@@ -27,13 +27,25 @@ ENV DATABASE_URL="postgresql://placeholder:placeholder@localhost:5432/placeholde
 # Datenbanken wechseln kann, siehe lib/prisma.ts.
 RUN pnpm build
 
-# --- Migrator-Tools -----------------------------------------------------
+# --- Migrator-Tools + Laufzeit-Zusatzpakete --------------------------------
 # 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
@@ -50,7 +62,8 @@ 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
+  @prisma/adapter-mariadb@^7.9.1 mariadb@^3.5.3 \
+  ffmpeg-static@^5.3.0
 
 # --- Runtime --------------------------------------------------------------
 FROM base AS runner