fix(sync): Teil-Abrufe verschlucken ihre Fehler nicht mehr

Behebt florian.wilde/nebula#19 und florian.wilde/nebula#20.

getJsonSafe machte aus jedem Fehlschlag eine leere Liste. Damit war ein
403 nicht mehr von "das Repository hat keine Branches" zu unterscheiden:
Der Abgleich lief durch, meldete "Snapshot aktualisiert: 0 Branches,
0 Tags", setzte kein syncError - und ueberschrieb dabei den letzten guten
Stand mit Nullen. Ein Repository mit 65 Commits sah danach aus wie ein
leeres, und die Ursache war nicht zu ermitteln, weil die Auskunft, die
sie benannt haette, gerade weggeworfen worden war.

Teilabrufe sammelt jetzt je Feld, was schiefging - mit HTTP-Status, denn
daran haengt die Ursache: 403 heisst Scopes, 429 Rate-Limit, 408
Zeitueberschreitung, 0 nicht erreicht. Der Fallback bleibt, ein einzelner
Fehlschlag darf den ganzen Abgleich nicht abbrechen.

Daraus folgt der zweite Teil: persistSnapshot laesst stehen, was nicht
geholt werden konnte. Der Snapshot ist ein Zwischenspeicher - ein alter
Stand mit sichtbarem Datum ist immer brauchbarer als eine leere Liste,
die aussieht wie eine Aussage. Die abgeleiteten Felder gehen mit ihrer
Liste: lastCommit* haengt an commits, latestTag an tags UND releases,
sonst waeren sie in sich widerspruechlich.

Bewusst kein Fehlschlag: syncError bleibt leer und der Zaehler fuers
Zurueckhalten steigt nicht. Der Rest des Standes ist frisch, und ein
Repository deswegen stundenlang auszusetzen waere die falsche Antwort.

GIT_API_TIMEOUT_MS wird geprueft. Number("") ist 0 und Number("abc") ist
NaN; setTimeout loest bei beidem sofort aus, und dann bricht jeder Aufruf
ab, bevor er beginnt. Eine verrutschte Zeile in der .env legte damit den
ganzen Abgleich still - lautlos, versteht sich.

NACHGEWIESEN, NICHT BEHAUPTET

Gegen einen nachgebauten Gitea-Server, der genau den beobachteten Fall
erzeugt - Basis-Aufruf antwortet, Teillisten geben 403 - und eine
Wegwerf-Datenbank:

  gesund      branchCount=2 tagCount=3 commits=2 releases=1 missing={}
  kaputt      branchCount=2 tagCount=3 commits=2 releases=1
              missing={8 Felder mit HTTP 403}, completeAt unveraendert
  wieder gut  missing={} , completeAt fortgeschrieben

Nichts verloren, die Luecke steht in der Meldung und am Repository, und
nach dem naechsten gesunden Durchlauf raeumt sie sich von selbst weg.
axe-core 0 Verstoesse auf 1280 und 375 px, kein seitlicher Ueberlauf.

Der eigentliche Grund der Ausfaelle auf der Instanz ist damit noch nicht
gefunden - aber ab jetzt steht er auf der Projektseite.

Refs #19
Refs #20

src/lib/git/http.ts

@@ -1,7 +1,37 @@
 import { BlockedHostError, assertAllowedUrl } from "@/lib/security/ssrf";
 import { GitApiError } from "./types";
 
-const DEFAULT_TIMEOUT = Number(process.env.GIT_API_TIMEOUT_MS ?? 15000);
+const TIMEOUT_VORGABE = 15000;
+
+/**
+ * Zeitlimit je Aufruf.
+ *
+ * Bewusst mit Pruefung: Number("") ist 0 und Number("abc") ist NaN – beides
+ * laesst setTimeout sofort ausloesen, und dann bricht jeder ausgehende
+ * Aufruf ab, bevor er begonnen hat. Eine verrutschte Zeile in der .env
+ * legte damit den ganzen Abgleich still, ohne dass irgendwo etwas stand.
+ */
+export function zeitlimit(
+  roh: string | undefined,
+  warnen: (text: string) => void = console.warn,
+): number {
+  const wert = roh?.trim();
+  if (!wert) return TIMEOUT_VORGABE;
+
+  const zahl = Number(wert);
+  // Untergrenze 1000 ms: darunter ist kein Aufruf ueber das Netz zu
+  // schaffen, und wer das eintraegt, hat sich vertan.
+  if (!Number.isFinite(zahl) || zahl < 1000) {
+    warnen(
+      `[nebula] GIT_API_TIMEOUT_MS="${wert}" ist unbrauchbar (Zahl ab 1000 erwartet). ` +
+        `Es gelten ${TIMEOUT_VORGABE} ms.`,
+    );
+    return TIMEOUT_VORGABE;
+  }
+  return zahl;
+}
+
+const DEFAULT_TIMEOUT = zeitlimit(process.env.GIT_API_TIMEOUT_MS);
 
 export interface FetchOptions {
   headers?: Record<string, string>;
@@ -73,7 +103,11 @@ export async function getJson<T>(
 
     if (!response.ok) {
       const body = await response.text().catch(() => "");
-      throw new GitApiError(friendlyMessage(response.status, url, body), response.status, url);
+      throw new GitApiError(
+        friendlyMessage(response.status, url, body),
+        response.status,
+        url,
+      );
     }
 
     const text = await response.text();
@@ -150,7 +184,11 @@ export async function sendJson<T>(
 
     if (!response.ok) {
       const text = await response.text().catch(() => "");
-      throw new GitApiError(friendlyMessage(response.status, url, text), response.status, url);
+      throw new GitApiError(
+        friendlyMessage(response.status, url, text),
+        response.status,
+        url,
+      );
     }
 
     const text = await response.text();
@@ -175,7 +213,14 @@ export async function sendJson<T>(
   }
 }
 
-/** Wie getJson, gibt aber bei jedem Fehler den Fallback zurueck. */
+/**
+ * Wie getJson, gibt aber bei jedem Fehler den Fallback zurueck.
+ *
+ * Nur fuer Abrufe benutzen, bei denen ein Fehlschlag wirklich nichts
+ * bedeutet. Fuer die Listen eines Snapshots ist das falsch – dort ist
+ * "nicht geholt" etwas anderes als "nichts vorhanden". Dafuer gibt es
+ * Teilabrufe.
+ */
 export async function getJsonSafe<T>(
   url: string,
   fallback: T,
@@ -189,6 +234,63 @@ export async function getJsonSafe<T>(
   }
 }
 
+/** Warum ein einzelner Teil-Abruf nicht geklappt hat. */
+export type Teilfehler = Record<string, string>;
+
+/**
+ * Sammelstelle fuer die Listen eines Snapshots.
+ *
+ * Der Vorgaenger dieser Klasse war ein getJsonSafe je Liste. Das hat jeden
+ * Fehler in eine leere Liste verwandelt, und damit war ein 403 nicht mehr
+ * von einem Repository ohne Branches zu unterscheiden: Der Abgleich meldete
+ * "Snapshot aktualisiert: 0 Branches, 0 Tags", schrieb Nullen ueber den
+ * letzten guten Stand und niemand konnte sehen, woran es lag.
+ *
+ * Der Fallback bleibt – ein einzelner Fehlschlag darf den ganzen Abgleich
+ * nicht abbrechen –, aber der Grund wird festgehalten.
+ */
+export class Teilabrufe {
+  readonly fehler: Teilfehler = {};
+
+  async hol<T>(
+    feld: string,
+    url: string,
+    fallback: T,
+    options: FetchOptions = {},
+  ): Promise<T> {
+    try {
+      const result = await getJson<T>(url, options);
+      return (result ?? fallback) as T;
+    } catch (error) {
+      this.fehler[feld] = beschreibe(error);
+      return fallback;
+    }
+  }
+
+  /** true, sobald mindestens ein Teil-Abruf gescheitert ist. */
+  get unvollstaendig(): boolean {
+    return Object.keys(this.fehler).length > 0;
+  }
+}
+
+/**
+ * Kurzfassung eines Fehlers, wie sie am Repository angezeigt wird.
+ *
+ * getJson gibt ausschliesslich GitApiError heraus – ein blockiertes Ziel
+ * kommt als 403, eine Zeitueberschreitung als 408, ein nicht erreichter
+ * Host als 0. Der Status ist damit die eigentliche Auskunft, und die
+ * uebrigen Zweige sind nur fuer den Fall da, dass sich das einmal aendert.
+ */
+function beschreibe(error: unknown): string {
+  if (error instanceof GitApiError) {
+    return error.status
+      ? `HTTP ${error.status}: ${error.message}`
+      : error.message;
+  }
+  if (error instanceof Error) return `${error.name}: ${error.message}`;
+  return String(error);
+}
+
 export function toIso(value: unknown): string | null {
   if (!value) return null;
   const date = new Date(String(value));