perf: hochgeladene Bilder und Videos schnell und vollstaendig ausliefern

Vier Befunde aus der Pruefung der Upload-Kette, alle am gemeinsamen
Datenpfad lib/uploads.ts und app/uploads/[...path]/route.ts:

1. Kein Range-Support. Die Ausliefer-Route beantwortete auch einen
   Range-Request mit einer vollstaendigen 200-Antwort. Ein <video> laedt
   sein Material grundsaetzlich per Range; iOS-Safari schickt zuerst die
   Probe "bytes=0-1" und spielt bei einer 200-Antwort gar nicht ab.
   Springen im Hero-Video war ebenfalls unmoeglich. Die Route beantwortet
   Bereichsanfragen jetzt mit 206 samt Content-Range, meldet
   Accept-Ranges und antwortet auf einen unerfuellbaren Bereich mit 416.

2. Ganze Datei im Speicher. readFile() las jede Datei vollstaendig in den
   RAM — bei einem Hero-Video bis MAX_UPLOAD_VIDEO_BYTES pro
   gleichzeitigem Zugriff. Ersetzt durch einen Stream von der Platte,
   inklusive Content-Length (vorher chunked, ohne Groessenangabe).

3. Keine bedingten Anfragen. Ohne ETag lud der Browser bei jedem Reload
   den vollen Bildinhalt erneut. ETag aus Groesse + Aenderungszeit, 304
   auf If-None-Match.

4. Bilder wurden in Originalaufloesung gespeichert. Ein 24-MP-Foto lag
   mit 6000x4000 und 9 MB auf dem Volume, und next/image musste dieses
   Bild fuer JEDE ausgelieferte Breite komplett neu dekodieren.
   reencodeImage() begrenzt jetzt auf MAX_IMAGE_DIMENSION (2560px lange
   Kante, Seitenverhaeltnis erhalten, kleinere Bilder werden nie
   hochskaliert).

Zusaetzlich MAX_UPLOAD_BYTES von 8 auf 25 MB angehoben: 8 MB lagen unter
dem, was aktuelle Handykameras routinemaessig erzeugen — ein normales
Foto brach mit "Die Datei ist zu gross" ab, obwohl es serverseitig
ohnehin verkleinert wird. Gegen eine Dekompressionsbombe (kleine Datei,
die sich zu Milliarden Pixeln entpackt) bekommt sharp mit
MAX_INPUT_PIXELS eine ausdrueckliche Obergrenze von 100 MP, die die
Byte-Grenze allein nicht abdeckt.

Gemessen an einem 10,17-MB-Foto mit 6000x4000: vorher mit 413 abgelehnt,
jetzt als 2560x1707 / 1,88 MB gespeichert; next/image kalt fuer 640px von
180 ms auf 65 ms.

Der Kommentar zur proxy-body-size in k8s/06-ingress.yaml nennt jetzt das
neue Bild-Limit; die Annotation selbst (110m) deckt es unveraendert ab.

src/app/uploads/[...path]/route.ts

@@ -1,6 +1,8 @@
 import { NextResponse } from "next/server";
-import { readFile } from "node:fs/promises";
-import { contentTypeForExtension, resolveUploadPath } from "@/lib/uploads";
+import { createReadStream } from "node:fs";
+import { stat } from "node:fs/promises";
+import { Readable } from "node:stream";
+import { contentTypeForExtension, parseRangeHeader, resolveUploadPath, uploadETag } from "@/lib/uploads";
 
 // node:fs braucht die Node-Runtime (nicht Edge).
 export const runtime = "nodejs";
@@ -10,28 +12,60 @@ export const runtime = "nodejs";
 // unter einem einmal ausgelieferten Pfad aendert sich also nie mehr.
 const CACHE_CONTROL = "public, max-age=31536000, immutable";
 
+function notFound(): NextResponse {
+  return NextResponse.json({ error: "Nicht gefunden." }, { status: 404 });
+}
+
 /**
- * Liefert hochgeladene Bilder (Inhalte-/Produkt-/Erntenfotos) aus, die unter
- * UPLOAD_DIR liegen. Next.js' statischer public/-Ordner wird zur Build-Zeit
- * fest ins Docker-Image gebacken und kann keine zur Laufzeit hinzugefuegten
- * Dateien ausliefern — dieser dynamische Route-Handler streamt sie
- * stattdessen direkt von der Platte (in Produktion ein SMB-Mount, siehe
- * UPLOAD_DIR in lib/uploads.ts).
+ * Header, die jede Antwort dieser Route traegt — auch 304 und 416, damit
+ * Caches und Browser in allen Faellen dieselbe Aussage ueber Cachebarkeit,
+ * Typ und Sniffing-Verbot sehen.
+ */
+function baseHeaders(contentType: string, etag: string): Record<string, string> {
+  return {
+    "Content-Type": contentType,
+    "Content-Disposition": "inline",
+    // Verhindert, dass der Browser den deklarierten Content-Type anhand
+    // des Inhalts "korrigiert" (MIME-Sniffing) — zusaetzliche Absicherung
+    // neben der festen Content-Type-Zuordnung unten.
+    "X-Content-Type-Options": "nosniff",
+    "Cache-Control": CACHE_CONTROL,
+    ETag: etag,
+    // Sagt dem Browser ueberhaupt erst, dass er Teilbereiche anfordern darf
+    // — ohne diesen Header versucht z.B. ein <video> gar keinen Range-
+    // Request und kann folglich auch nicht springen.
+    "Accept-Ranges": "bytes",
+  };
+}
+
+/**
+ * Liefert hochgeladene Bilder und Videos (Inhalte-/Produkt-/Erntenfotos,
+ * Hero-Video) aus, die unter UPLOAD_DIR liegen. Next.js' statischer
+ * public/-Ordner wird zur Build-Zeit fest ins Docker-Image gebacken und kann
+ * keine zur Laufzeit hinzugefuegten Dateien ausliefern — dieser dynamische
+ * Route-Handler streamt sie stattdessen direkt von der Platte (in Produktion
+ * ein gemountetes Volume, siehe UPLOAD_DIR in lib/uploads.ts).
  *
- * Oeffentlich erreichbar ohne Admin-Pruefung (die Bilder sind fuer die
+ * Die Datei wird als Stream durchgereicht statt vollstaendig in den Speicher
+ * gelesen: ein Hero-Video darf bis zu MAX_UPLOAD_VIDEO_BYTES gross sein, und
+ * dessen kompletter Inhalt pro gleichzeitigem Zugriff im RAM waere weder
+ * noetig noch tragbar. Unterstuetzt werden ausserdem bedingte Anfragen
+ * (If-None-Match -> 304) und Bereichsanfragen (Range -> 206), letzteres ist
+ * Voraussetzung dafuer, dass ein <video> ueberhaupt abspielbar und
+ * springbar ist (siehe parseRangeHeader in lib/uploads.ts).
+ *
+ * Oeffentlich erreichbar ohne Admin-Pruefung (die Dateien sind fuer die
  * oeffentlichen Shop-/Homepage-Seiten bestimmt) — geschuetzt wird stattdessen
  * NUR das Schreiben (app/api/admin/upload/route.ts).
  */
 export async function GET(
-  _request: Request,
+  request: Request,
   { params }: { params: Promise<{ path: string[] }> }
 ) {
   const { path: segments } = await params;
 
   const resolved = resolveUploadPath(segments);
-  if (!resolved) {
-    return NextResponse.json({ error: "Nicht gefunden." }, { status: 404 });
-  }
+  if (!resolved) return notFound();
 
   const extension = resolved.slice(resolved.lastIndexOf(".") + 1).toLowerCase();
   // Content-Type kommt ausschliesslich aus dieser festen Zuordnung nach
@@ -42,26 +76,56 @@ export async function GET(
   // ausgeliefert; alles andere unter UPLOAD_DIR bleibt ueber diese Route
   // unerreichbar.
   const contentType = contentTypeForExtension(extension);
-  if (!contentType) {
-    return NextResponse.json({ error: "Nicht gefunden." }, { status: 404 });
-  }
+  if (!contentType) return notFound();
 
-  let data: Buffer;
+  let size: number;
+  let mtimeMs: number;
   try {
-    data = await readFile(resolved);
+    const stats = await stat(resolved);
+    // Ein Verzeichnis unter einem erlaubten Namen (theoretisch anlegbar auf
+    // dem gemounteten Volume) darf nicht als Datei ausgeliefert werden.
+    if (!stats.isFile()) return notFound();
+    size = stats.size;
+    mtimeMs = stats.mtimeMs;
   } catch {
-    return NextResponse.json({ error: "Nicht gefunden." }, { status: 404 });
+    return notFound();
   }
 
-  return new NextResponse(new Uint8Array(data), {
-    headers: {
-      "Content-Type": contentType,
-      "Content-Disposition": "inline",
-      // Verhindert, dass der Browser den deklarierten Content-Type anhand
-      // des Inhalts "korrigiert" (MIME-Sniffing) — zusaetzliche Absicherung
-      // neben der festen Content-Type-Zuordnung oben.
-      "X-Content-Type-Options": "nosniff",
-      "Cache-Control": CACHE_CONTROL,
-    },
+  const etag = uploadETag(size, mtimeMs);
+  const headers = baseHeaders(contentType, etag);
+
+  // Bedingte Anfrage: der Browser hat die Datei bereits und fragt nur, ob
+  // sie noch aktuell ist. 304 spart die gesamte Nutzlast.
+  if (request.headers.get("if-none-match") === etag) {
+    return new NextResponse(null, { status: 304, headers });
+  }
+
+  const range = parseRangeHeader(request.headers.get("range"), size);
+
+  if (range === "unsatisfiable") {
+    return new NextResponse(null, {
+      status: 416,
+      headers: { ...headers, "Content-Range": `bytes */${size}` },
+    });
+  }
+
+  if (range) {
+    const length = range.end - range.start + 1;
+    const stream = Readable.toWeb(
+      createReadStream(resolved, { start: range.start, end: range.end })
+    ) as ReadableStream<Uint8Array>;
+    return new NextResponse(stream, {
+      status: 206,
+      headers: {
+        ...headers,
+        "Content-Range": `bytes ${range.start}-${range.end}/${size}`,
+        "Content-Length": String(length),
+      },
+    });
+  }
+
+  const stream = Readable.toWeb(createReadStream(resolved)) as ReadableStream<Uint8Array>;
+  return new NextResponse(stream, {
+    headers: { ...headers, "Content-Length": String(size) },
   });
 }