feat(llm): Download-Fortschritt beim Modell-Laden — und "Laden" kommt endlich an

Eigentlicher Fehler zuerst: llm_provision_model/_result und llm_remove_model
standen nie in der RVS-Allow-List. Der RVS verwirft unbekannte Typen mit einem
stillen return — jeder Klick auf "Laden" im Modell-Katalog ist seit Stage D
(19.09.) an dieser Liste gestorben, die Box hat nie davon erfahren. Laden
liessen sich nur die Modelle aus der Basis-Config der Box.

Gefunden, weil grep rvs/server.js fuer eine Binaerdatei hielt und still
uebersprang: in Zeile 164 stand seit a7998bcd ein ECHTES Nullbyte im
Template-String statt eines Escapes. Node stoert das nicht, aber git zeigte
fuer jede Aenderung am RVS nur noch "Binary files differ". Jetzt \u0000 —
zur Laufzeit derselbe String.

Fortschritt: llama.cpp zieht das GGUF per -hf selbst und meldet nichts. Der
llm-adapter fragt vorab bei Hugging Face, welche Dateien (Groesse, sha256)
kommen, und misst genau diese im HF-Cache-Layout, das llama.cpp verwendet:
  /models/models--org--repo/blobs/<sha256>.downloadInProgress  (waechst)
  /models/models--org--repo/blobs/<sha256>                     (fertig)
Layout gegen den echten llama.cpp-Server ausprobiert, nicht angenommen. Geht
auch bei gesplitteten Modellen und zwei Downloads gleichzeitig; Fallback fuer
aeltere Layouts ueber alle *.downloadInProgress. Phasen: queued → start →
download (%, MB/s, Restzeit) → load ("laedt in die Karte") → ready ("in Karte
N geladen", Name + VRAM aus nvidia-smi) bzw. error.

Mitgefixt: der Warmup wartete LLM_TIMEOUT_SEC (Default 60 s). Ein Modell mit
mehreren GB meldete deshalb "Fehler", waehrend llama-swap weiterlud. Jetzt
LLM_WARMUP_TIMEOUT_S (1900 s, ueber llama-swaps healthCheckTimeout).

Diagnostic: Knopf "⬇ Downloads" neben "Von HuggingFace aktualisieren" mit
Zaehler fuer laufende; "Laden" oeffnet das Fenster direkt. Der Server merkt
sich den Stand pro (Box, Modell), ein spaeter geoeffneter Tab sieht laufende
Downloads. Antwortet die Box nicht, steht nach 30 s eine Warnung da statt
nichts.

Compose (KI-Box): llm-adapter bekommt LLM_GPU (Karte fuer die Meldung) und
HF_TOKEN (Dateiliste gesperrter Repos).

Test: Fortschritt gegen einen echten llama.cpp-Download (Qwen2.5-0.5B Q8,
676 MB): Prozent steigend 0 → 91.6, dann load; zweiter Lauf aus dem Cache
direkt load mit cached=true.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

rvs/server.js

@@ -124,6 +124,11 @@ const ALLOWED_TYPES = new Set([
   // OpenAI-Endpunkt einer LLM-Box: Diagnostic setzt den API-Key (der PORT kommt
   // immer aus der .env der Box — er ist ein Docker-Port-Mapping).
   "llm_openai_config", "llm_openai_config_result",
+  // Modell auf eine LLM-Box laden (Diagnostic → Modell-Katalog → „Laden").
+  // Fehlten hier seit Stage D: jeder Klick auf „Laden" starb still an dieser
+  // Liste, die Box hat nie davon erfahren. _progress meldet den Download in %.
+  "llm_provision_model", "llm_provision_result", "llm_provision_progress",
+  "llm_remove_model",
   "node_stats", "node_stats_stream_start", "node_stats_stream_stop",
   "node_stats_history_request", "node_stats_history",
   "node_stats_reset", "node_stats_reset_done",
@@ -161,7 +166,7 @@ const pendingReplies = new Map();
 const PENDING_TTL_MS = 180_000;
 
 function pendingKey(replyType, requestId) {
-  return `${replyType}${requestId}`;
+  return `${replyType}\u0000${requestId}`;
 }
 
 /** Merkt sich den Fragenden, wenn die Nachricht eine gezielte Anfrage ist. */