feat: Bild-Upload fuer Inhalte, Produkte und Ernten

Echter Datei-Upload statt CSS-Platzhaltergrafiken, gespeichert unter
UPLOAD_DIR (Laufzeit-Verzeichnis, weiss nichts von seiner tatsaechlichen
Speicher-Anbindung — in Produktion ein von der Betreiberin selbst per
Kubernetes eingebundenes Volume, z.B. SMB; lokal ein simples ./uploads).

- lib/uploads.ts: Kernlogik. Bildformat wird ausschliesslich aus den
  tatsaechlichen Bilddaten erkannt (Magic-Bytes via sharp), nie aus
  Client-Dateiname/MIME-Type. Zufaellige, nicht erratbare Dateinamen
  (Path-Traversal-/Overwrite-Schutz). Re-Encoding validiert Pixel-Daten
  vollstaendig und entfernt eingebettete Metadaten (EXIF/ICC/XMP) als
  Nebeneffekt. Content-Type beim Ausliefern kommt ausschliesslich aus
  einer festen Endung->MIME-Zuordnung, nie aus Dateiinhalt/-namen.
- app/api/admin/upload/route.ts: Admin-only Upload-Endpunkt (CSRF- +
  Auth- + Rate-Limit-Pruefung, max. 8 MB, JPEG/PNG/WebP/AVIF).
- app/uploads/[...path]/route.ts: liefert hochgeladene Bilder aus
  (public/ wird zur Build-Zeit fest ins Image gebacken, kann also keine
  zur Laufzeit hinzugefuegten Dateien bedienen) — mit
  Path-Traversal-Schutz und nosniff-Header.
- content-registry.ts: neuer "image"-Feldtyp fuer Hero-/Startseite-
  Grafiken, admin/inhalte hat dafuer ein Upload-Widget.
- Produkt-/Ernten-Admin-Formulare: Mehrfach-Bild-Upload fuer
  Product.images/Harvest.images (beide Felder existierten im Schema,
  hatten aber bislang keine Admin-Oberflaeche). Oeffentliche Seiten
  (Shop, Ernten, Chargen-QR-Seite) zeigen jetzt echte Fotos statt
  Platzhalter, sobald vorhanden.
- Kubernetes: nur ein einfacher volumeMount in 05-app-deployment.yaml
  (Platzhalter-emptyDir, klar als CHANGE-ME markiert) — die eigentliche
  Volume-Quelle (SMB o.ae.) bindet die Betreiberin selbst ein, wie
  gewuenscht keine SMB/CSI-spezifischen Manifeste hinzugefuegt.

Verifiziert: tsc --noEmit clean, 139/139 Tests gruen (21 neu), pnpm
build clean. Upload-/Serving-Pipeline live gegen einen laufenden
Server getestet (Auth-/CSRF-Gates, Path-Traversal-Ablehnung,
Format-Ablehnung) — ein vollstaendiger authentifizierter Upload
end-to-end (braucht echten Admin-Login inkl. 2FA) wurde nicht live
durchgespielt, nur per Code-Review verifiziert.

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

.env.example

@@ -159,3 +159,20 @@ ENTRA_TENANT_ID=
 ENTRA_CLIENT_ID=
 ENTRA_CLIENT_SECRET=
 ENTRA_REDIRECT_URI=http://localhost:3000/api/auth/entra/callback
+
+# Verzeichnis fuer hochgeladene Bilder (Inhalte-Bild in admin/inhalte,
+# Produkt-/Erntenfotos in admin/produkte bzw. admin/ernten — siehe
+# app/api/admin/upload/route.ts und app/uploads/[...path]/route.ts). Die App
+# liest/schreibt hier ganz normal per node:fs; sie weiss nichts davon, WAS
+# dieses Verzeichnis in Produktion ist (siehe unten).
+#
+# 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
+# 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
+# PersistentVolume; UPLOAD_DIR muss nur exakt auf den gewaehlten mountPath
+# zeigen.
+UPLOAD_DIR=./uploads