fix: Ingress-Zeitlimits und Speicherbudget fuer den Video-Upload setzen

Zwei Einstellungen im Deployment liessen einen Video-Upload scheitern,
bevor die Anwendung ueberhaupt antworten konnte — beide Male mit einer
HTML-Fehlerseite, die im Browser als "Unexpected token '<'" ankam:

1. Der Ingress trug keinerlei Timeout-Annotation. ingress-nginx wartet
   dann nur 60 Sekunden je Phase und liefert danach eine eigene
   HTML-504-Seite. Ein Video-Upload braucht regelmaessig laenger: erst
   muessen bis zu 100 MB ueber die Leitung, danach rechnet ffmpeg das
   Video fuers Web um. proxy-read-timeout und proxy-send-timeout stehen
   jetzt auf 600s — bewusst oberhalb des harten ffmpeg-Zeitlimits von 5
   Minuten, damit im Zweifel die Anwendung selbst mit einer verwertbaren
   JSON-Meldung abbricht statt nginx die Verbindung zu kappen.

2. Das Speicherlimit von 512Mi war fuer einen 100-MB-Upload zu knapp:
   request.formData() laedt den multipart-Body vollstaendig in den
   Speicher, und der Kernel beendet den Prozess bei Ueberschreitung
   (OOMKilled). Limit auf 1Gi, Request auf 512Mi. Der CPU-Request steigt
   von 100m auf 500m, weil ffmpeg CPU-gebunden ist und mit 100m ein
   Vielfaches der Zeit braucht — bewusst weiterhin ohne CPU-Limit, das
   wuerde den Transcode auch auf einem freien Knoten drosseln.

Der Kommentar nennt zusaetzlich das davon unabhaengige Origin-Zeitlimit
eines vorgeschalteten CDN (bei Cloudflare 100 Sekunden, Fehler 524), das
sich hier nicht beeinflussen laesst.

k8s/05-app-deployment.yaml

@@ -78,12 +78,32 @@ spec:
             initialDelaySeconds: 30
             periodSeconds: 30
             failureThreshold: 5
+          # Bemessen nach dem teuersten Vorgang der Anwendung, dem
+          # Admin-Video-Upload: Node laedt den multipart-Body beim
+          # request.formData() vollstaendig in den Speicher, und die Datei
+          # darf bis zu 100 MB gross sein (MAX_UPLOAD_VIDEO_BYTES in
+          # lib/uploads.ts). Zusammen mit dem Grundverbrauch des
+          # Next.js-Servers sprengte das ein Limit von 512Mi — der Kernel
+          # beendet den Prozess dann mitten im Upload (OOMKilled), und im
+          # Browser kommt davon nur die HTML-Fehlerseite des Reverse-Proxy an
+          # ("Unexpected token '<', "<!DOCTYPE "... is not valid JSON").
+          #
+          # Die Route selbst haelt inzwischen nur noch den Body im Speicher
+          # und streamt alles Weitere ueber die Platte (siehe
+          # app/api/admin/upload-video/route.ts) — 1Gi gibt darueber hinaus
+          # Reserve, damit ein zweiter gleichzeitiger Zugriff den Pod nicht
+          # kippt.
+          #
+          # ffmpeg ist CPU-gebunden: mit nur 100m dauert das Umrechnen ein
+          # Vielfaches und laeuft eher in ein Proxy-Zeitlimit. Bewusst KEIN
+          # CPU-Limit, nur ein hoeherer Request — ein Limit wuerde den
+          # Transcode hart drosseln, auch wenn der Knoten gerade frei ist.
           resources:
             requests:
-              cpu: 100m
-              memory: 256Mi
-            limits:
+              cpu: 500m
               memory: 512Mi
+            limits:
+              memory: 1Gi
       volumes:
         # Platzhalter — die Betreiberin ergaenzt hier ihre eigene
         # Volume-Quelle fuer den Namen "uploads" (z.B. ein PVC, das gegen