fix: Admin-Uploads auf dem Live-Server (Berechtigung, Persistenz, Body-Size-Limit)

Uploads (Bilder + Hero-Video) schlugen live fehl, lokal aber nicht: der
Container laeuft als non-root "nextjs", /app/uploads existierte nirgends
vorbereitet und gehoert root -> mkdir() scheiterte mit EACCES, unbehandelt
als HTML-500 statt JSON, der Client zeigte nur einen haengenden
"wird hochgeladen"-Zustand ohne Fehlermeldung.

- Dockerfile legt /app/uploads jetzt vor dem User-Wechsel an und
  uebereignet es dem nextjs-Nutzer
- docker-compose.yml persistiert Uploads jetzt ueber ein eigenes Volume
  (vorher gingen sie bei jedem Redeploy verloren) und setzt UPLOAD_DIR
  explizit
- Beide Upload-Routen fangen Dateisystemfehler jetzt ab und liefern eine
  echte JSON-Fehlermeldung statt eine unbehandelte Exception
- k8s-Manifeste vorsorglich mitgefixt (fsGroup fuer den Volume-Mount,
  Ingress-Body-Size-Limit) fuer den Fall eines spaeteren
  Kubernetes-Wechsels

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

.env.example

@@ -169,7 +169,11 @@ ENTRA_REDIRECT_URI=http://localhost:3000/api/auth/entra/callback
 # Lokal reicht der Default "./uploads" (relativ zum Projektverzeichnis, per
 # .gitignore ausgeschlossen — beim ersten Upload automatisch angelegt).
 #
-# In Produktion (Kubernetes, siehe k8s/05-app-deployment.yaml) zeigt
+# In docker-compose.yml ist UPLOAD_DIR bereits fest auf /app/uploads gesetzt
+# und ueber ein benanntes Docker-Volume persistiert (siehe dort) — hier
+# nichts weiter noetig, dieser Wert wirkt nur fuer lokales "npm run dev".
+#
+# In Produktion per Kubernetes (siehe k8s/05-app-deployment.yaml) zeigt
 # UPLOAD_DIR stattdessen auf einen Volume-Mount, damit hochgeladene Bilder
 # einen Pod-Neustart/-Redeploy ueberleben — welche Art Volume das konkret
 # ist (SMB/NFS/hostPath/...), entscheidet die Betreiberin beim Anlegen des