fix: Video-Upload startet den Pod nicht mehr neu

Ein Video ueber 50 MB im Admin hochzuladen, liess den Pod mitten im Upload
neu starten. Ursache war nicht die Dateigroesse, sondern dass ffmpeg sich
nach den Kernen des KNOTENS bemessen hat statt nach dem CPU-Anteil des Pods.

x264 waehlt seine Threadzahl standardmaessig als das 1,5-fache der vom
Betriebssystem gemeldeten Kerne. In einem Container sind das die Kerne des
Knotens: auf einer 16-Kern-Maschine rund 24 Encoder-Threads mit je eigenen
Bildpuffern, bei 4K-Material rund 12 MB je Bild. Das hatte zwei Folgen, die
von aussen beide gleich aussehen:

1. Der Speicherbedarf sprengte das Speicherlimit des Pods, der Kernel
   beendete den Container (OOMKilled).
2. ffmpeg belegte alle Kerne, der Node-Prozess kam nicht mehr zum Zug und
   beantwortete die Liveness-Probe nicht rechtzeitig. Kubelet wertete das
   als haengenden Prozess und startete den Container neu.

Dekoder-, Filter- und Encoder-Threads sind jetzt gedeckelt (Vorgabe 2, ueber
VIDEO_TRANSCODE_THREADS auf bis zu 8 anhebbar). Der Verbrauch ist damit
konstant und unabhaengig davon, auf welchem Knoten der Pod laeuft. Der
"-threads"-Deckel steht bewusst auch VOR "-i": ffmpeg ordnet Optionen der
naechsten Datei zu, ein Deckel erst hinter "-i" wuerde nur den Encoder
begrenzen und das Dekodieren eines 4K-Videos unbegrenzt lassen.

Zusaetzlich "-nostdin" und stdio ["ignore","ignore","pipe"]: der
Kindprozess bekam von spawn() eine Standardeingabe, die niemand bedient,
und eine unbeachtete stdout-Pipe, die volllaufen kann. Beides konnte
ffmpeg bis zum Zeitlimit blockieren.

Die Argumentliste ist als buildFfmpegArgs() ausgelagert und getestet, damit
die Begrenzungen pruefbar sind, ohne ffmpeg wirklich zu starten.

Beide Probes bekommen ausserdem timeoutSeconds: 5. Ohne den Eintrag gilt
Kubernetes' Vorgabe von einer Sekunde — zu knapp, solange sich der
Node-Prozess die CPU mit einem laufenden Transcode teilt. k8s/README.md
beschreibt die Diagnose fuer den Fall, dass im Cluster noch eine aeltere,
von Hand gepflegte Fassung des Deployments laeuft.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

.env.example

@@ -193,3 +193,15 @@ ENTRA_REDIRECT_URI=http://localhost:3000/api/auth/entra/callback
 # PersistentVolume; UPLOAD_DIR muss nur exakt auf den gewaehlten mountPath
 # zeigen.
 UPLOAD_DIR=./uploads
+
+# Threads, die ffmpeg beim Umrechnen eines hochgeladenen Videos benutzen darf
+# (Admin -> Inhalte -> Hero-Video). Leer lassen heisst 2, erlaubt sind 1 bis 8.
+#
+# NICHT hochsetzen, um den Upload zu beschleunigen, ohne gleichzeitig das
+# Speicherlimit des Pods zu pruefen: x264 haelt pro Thread eigene Bildpuffer,
+# bei 4K-Material rund 12 MB je Bild. Ohne Deckel richtet sich ffmpeg nach den
+# Kernen des KUBERNETES-KNOTENS statt nach dem CPU-Anteil des Pods — auf einem
+# grossen Knoten sprengt das sowohl den Speicher des Pods als auch die
+# Liveness-Probe, und der Container wird mitten im Upload neu gestartet.
+# Ausfuehrliche Begruendung in src/lib/video-transcode.ts.
+VIDEO_TRANSCODE_THREADS=