fix: Video-Upload scheiterte, weil ffmpeg-static mitgebuendelt wurde

Jeder Video-Upload ohne System-ffmpeg im PATH — also jede lokale
Entwicklungsumgebung unter Windows/macOS — endete mit 400 "Das Video
konnte nicht verarbeitet werden.". Im Server-Log stand der eigentliche
Grund:

  spawn \ROOT\node_modules\.pnpm\[email protected]\...\ffmpeg.exe ENOENT

ffmpeg-static exportiert den Pfad zu seiner mitgelieferten Binary
__dirname-relativ. Wird das Paket vom Bundler mitgebuendelt, zeigt sein
__dirname auf einen virtuellen Bundle-Pfad ("/ROOT/...") statt auf das
echte Verzeichnis in node_modules — genau dieselbe Ursache, aus der
pdfkit hier schon als serverExternalPackage gefuehrt wird.

ffmpeg-static daher ebenfalls in serverExternalPackages aufgenommen; der
Kommentar erklaert die Ursache jetzt einmal fuer beide Pakete. Der
Standalone-Build kopiert das Paket damit unveraendert nach
node_modules (verifiziert).

next.config.ts

@@ -9,12 +9,21 @@ const nextConfig: NextConfig = {
   // wodurch das Docker-Image (siehe Dockerfile) deutlich kleiner bleibt.
   output: "standalone",
 
-  // pdfkit laedt seine Schriftart-Metadaten (.afm-Dateien) zur Laufzeit ueber
-  // einen eigenen __dirname-relativen Pfad. Wird das Paket vom Bundler
-  // (Turbopack/Webpack) mitgebuendelt, geht dieser Pfad verloren (ENOENT).
-  // "serverExternalPackages" laesst Next.js es stattdessen ganz normal per
-  // require() aus node_modules laden.
-  serverExternalPackages: ["pdfkit"],
+  // Pakete, die zur Laufzeit eigene Dateien ueber einen __dirname-relativen
+  // Pfad nachladen. Werden sie vom Bundler (Turbopack/Webpack) mitgebuendelt,
+  // zeigt ihr __dirname auf einen virtuellen Bundle-Pfad ("/ROOT/...") statt
+  // auf das echte Verzeichnis in node_modules — der Zugriff schlaegt dann mit
+  // ENOENT fehl. "serverExternalPackages" laesst Next.js sie stattdessen ganz
+  // normal per require() aus node_modules laden.
+  //
+  // - pdfkit: laedt seine Schriftart-Metadaten (.afm-Dateien).
+  // - ffmpeg-static: exportiert den Pfad zur mitgelieferten ffmpeg-Binary
+  //   (siehe lib/video-transcode.ts). Gebuendelt lieferte es
+  //   "\ROOT\node_modules\...\ffmpeg.exe" -> jeder Video-Upload ohne
+  //   System-ffmpeg im PATH (also jede lokale Entwicklungsumgebung unter
+  //   Windows/macOS) scheiterte mit "Das Video konnte nicht verarbeitet
+  //   werden."
+  serverExternalPackages: ["pdfkit", "ffmpeg-static"],
 
   // Turbopacks Dateisystem-Caches (.next/dev/cache & .next/cache/turbopack)
   // kollidieren in diesem OneDrive-synchronisierten Arbeitsverzeichnis