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/lib/uploads.ts

@@ -24,13 +24,41 @@ import sharp from "sharp";
 export const UPLOAD_DIR = path.resolve(/*turbopackIgnore: true*/ process.env.UPLOAD_DIR || "./uploads");
 
 /**
- * 8 MB: grosszuegig genug fuer ein einzelnes unkomprimiertes Foto aus einer
- * aktuellen Smartphone-Kamera nach Export, aber klein genug, um den Server
- * nicht mit riesigen Uploads zu belasten — die Datei wird vollstaendig in
- * den Speicher gelesen (kein Streaming), um sie mit sharp zu validieren und
- * neu zu enkodieren.
+ * 25 MB fuer die HOCHGELADENE Rohdatei. Die vorherigen 8 MB lagen unter der
+ * Groesse, die aktuelle Handykameras (48 MP, HEIC-Export nach JPEG)
+ * routinemaessig erzeugen — ein voellig normales Foto brach damit mit "Die
+ * Datei ist zu gross" ab. Was tatsaechlich gespeichert wird, ist ohnehin
+ * nicht diese Rohdatei, sondern das von reencodeImage() auf
+ * MAX_IMAGE_DIMENSION verkleinerte und neu enkodierte Ergebnis (in aller
+ * Regel ein Bruchteil davon).
+ *
+ * Die Datei wird zur Validierung vollstaendig in den Speicher gelesen (kein
+ * Streaming); gegen ein kleines File, das sich beim Dekodieren zu absurd
+ * vielen Pixeln aufblaeht, schuetzt zusaetzlich MAX_INPUT_PIXELS.
  */
-export const MAX_UPLOAD_BYTES = 8 * 1024 * 1024;
+export const MAX_UPLOAD_BYTES = 25 * 1024 * 1024;
+
+/**
+ * Laengste Kante, mit der ein Bild gespeichert wird. 2560px deckt jede
+ * Darstellung dieser Seite mit Reserve ab — das groesste Layout ist ein
+ * vollbreiter Hero, und selbst ein Display mit doppelter Pixeldichte
+ * verlangt davon keine hoehere Aufloesung. Alles darueber kostete nur Platz
+ * auf dem Upload-Volume und zwang next/image, fuer JEDE ausgelieferte
+ * Breite das komplette Originalbild neu zu dekodieren (ein 6000x4000-Foto
+ * sind 24 Megapixel pro Variante).
+ */
+export const MAX_IMAGE_DIMENSION = 2560;
+
+/**
+ * Obergrenze fuer die Pixelzahl, die sharp aus einer hochgeladenen Datei
+ * ueberhaupt dekodieren darf (100 MP — mehr als jede Kamera liefert, die
+ * hier realistisch zum Einsatz kommt). Schuetzt vor einer "Dekompressions-
+ * bombe": einer wenige Kilobyte grossen Datei, die sich zu Milliarden
+ * Pixeln entpackt und damit den Arbeitsspeicher des Servers fuellt — die
+ * Byte-Grenze MAX_UPLOAD_BYTES allein faengt das nicht ab, weil sie nur die
+ * komprimierte Groesse kennt.
+ */
+export const MAX_INPUT_PIXELS = 100_000_000;
 
 /**
  * 100 MB: deckt auch ein laengeres oder nicht web-optimiertes Hero-Video
@@ -176,10 +204,24 @@ export function resolveUploadPath(segments: string[]): string | null {
  * Argumente richtet das Bild einmalig anhand des EXIF-Orientation-Tags aus,
  * BEVOR dieser Tag mit den uebrigen Metadaten verworfen wird — sonst
  * erschiene ein am Handy "hochkant" aufgenommenes Foto nach dem Entfernen
- * der Metadaten seitlich verdreht.
+ * der Metadaten seitlich verdreht. Zusaetzlich (3) wird das Bild auf
+ * MAX_IMAGE_DIMENSION begrenzt, damit nie mehr Aufloesung gespeichert wird,
+ * als die Seite je ausliefert.
  */
 export async function reencodeImage(buffer: Buffer, extension: AllowedImageExtension): Promise<Buffer> {
-  const image = sharp(buffer).rotate();
+  const image = sharp(buffer, { limitInputPixels: MAX_INPUT_PIXELS })
+    .rotate()
+    // "inside" skaliert so, dass BEIDE Kanten in das Quadrat passen — bei
+    // einem Querformat greift damit die Breite, bei einem Hochformat die
+    // Hoehe, das Seitenverhaeltnis bleibt in beiden Faellen erhalten.
+    // "withoutEnlargement" stellt sicher, dass ein ohnehin kleineres Bild
+    // nie hochskaliert (und damit unscharf) wird.
+    .resize({
+      width: MAX_IMAGE_DIMENSION,
+      height: MAX_IMAGE_DIMENSION,
+      fit: "inside",
+      withoutEnlargement: true,
+    });
   switch (extension) {
     case "jpg":
       return image.jpeg({ quality: 85 }).toBuffer();
@@ -191,3 +233,78 @@ export async function reencodeImage(buffer: Buffer, extension: AllowedImageExten
       return image.avif({ quality: 60 }).toBuffer();
   }
 }
+
+/** Ein halboffenes Byte-Intervall, beide Grenzen inklusive (wie im HTTP-Header). */
+export interface ByteRange {
+  start: number;
+  end: number;
+}
+
+/**
+ * Wertet einen HTTP-Range-Header gegen die bekannte Dateigroesse aus.
+ *
+ * Warum das gebraucht wird: ein <video src="/uploads/..."> (siehe
+ * components/hero.tsx) laedt sein Material grundsaetzlich per Range-Request.
+ * iOS-Safari schickt dafuer zuerst eine Ein-Byte-Probe ("bytes=0-1") und
+ * spielt das Video ueberhaupt nicht ab, wenn der Server darauf mit einer
+ * vollstaendigen 200-Antwort statt mit "206 Partial Content" antwortet.
+ * Ohne Range-Unterstuetzung laesst sich ausserdem nirgends im Video
+ * springen, und jeder Abspielversuch laedt die komplette Datei.
+ *
+ * Rueckgabe:
+ * - `null`      -> kein (oder kein auswertbarer) Range-Wunsch, ganze Datei
+ *                  ausliefern. Laut RFC 9110 ist das auf JEDEN Range-Request
+ *                  eine zulaessige Antwort, deshalb werden auch mehrteilige
+ *                  und kaputte Bereiche hierher abgebildet statt als Fehler.
+ * - `"unsatisfiable"` -> syntaktisch gueltig, aber ausserhalb der Datei:
+ *                  muss mit 416 beantwortet werden.
+ * - `ByteRange` -> der auf die Dateigroesse zugeschnittene Bereich.
+ */
+export function parseRangeHeader(header: string | null, size: number): ByteRange | "unsatisfiable" | null {
+  if (!header) return null;
+
+  const match = /^bytes=(.+)$/i.exec(header.trim());
+  if (!match) return null;
+
+  const spec = match[1].trim();
+  // Mehrteilige Bereiche braeuchten eine multipart/byteranges-Antwort — fuer
+  // Bilder/Videos praktisch nie angefragt, deshalb bewusst nicht unterstuetzt.
+  if (spec.includes(",")) return null;
+
+  const parts = /^(\d*)-(\d*)$/.exec(spec);
+  if (!parts) return null;
+  const [, rawStart, rawEnd] = parts;
+  if (rawStart === "" && rawEnd === "") return null;
+
+  // Eine leere Datei kann keinen einzigen Bereich erfuellen.
+  if (size <= 0) return "unsatisfiable";
+  const lastByte = size - 1;
+
+  // Suffix-Form "bytes=-N": die LETZTEN N Bytes, nicht "ab Byte N".
+  if (rawStart === "") {
+    const suffixLength = Number(rawEnd);
+    if (!Number.isSafeInteger(suffixLength) || suffixLength <= 0) return "unsatisfiable";
+    return { start: Math.max(0, size - suffixLength), end: lastByte };
+  }
+
+  const start = Number(rawStart);
+  if (!Number.isSafeInteger(start) || start > lastByte) return "unsatisfiable";
+
+  if (rawEnd === "") return { start, end: lastByte };
+
+  const requestedEnd = Number(rawEnd);
+  if (!Number.isSafeInteger(requestedEnd) || requestedEnd < start) return "unsatisfiable";
+  return { start, end: Math.min(requestedEnd, lastByte) };
+}
+
+/**
+ * Validator fuer bedingte Anfragen (If-None-Match). Dateigroesse und
+ * Aenderungszeit genuegen als Kennung, weil eine hochgeladene Datei unter
+ * ihrem zufaelligen Namen nie ueberschrieben wird (siehe
+ * generateUploadFilename) — ein Wechsel beider Werte ist daher ohnehin nur
+ * bei einer echten Neuanlage moeglich. Erspart dem Browser bei jedem Reload
+ * das erneute Herunterladen des Bildinhalts (304 statt 200).
+ */
+export function uploadETag(size: number, mtimeMs: number): string {
+  return `"${size.toString(16)}-${Math.floor(mtimeMs).toString(16)}"`;
+}