Enable llama.cpp builds, release management and reference model auto-fit

DEVELOPMENT.md

@@ -7,7 +7,7 @@ Editor/SSH-Client und Browser. Die Anwendung und ihre Tests laufen auf Athena.
 - Eigener Container: `athena-deck-dev`
 - Zustand und Installationsmanifest: `/opt/athena-deck-dev/runtime`
 - Serverbindung: ausschließlich `127.0.0.1:8108`
-- GPU-Zugriff: NVIDIA `utility` für Telemetrie; keine Modellstarts.
+- GPU-Zugriff: NVIDIA `compute,utility` für Telemetrie und Fit-Prüfung; keine Modellstarts.
 
 Vom Arbeitsplatz:
 
@@ -72,3 +72,65 @@ noch keine vollständige Installation eines mehrteiligen Modells dar.
 
 Update-Sicherungen enthalten den Konfigurationszustand, nicht die heruntergeladenen
 Modelldateien. Diese bleiben im persistenten Zustandsverzeichnis erhalten.
+
+## Native Laufzeitverwaltung
+
+`runtime.py` verwendet ausschließlich native Prozesse (git, cmake, llama-server),
+keine Docker-API. Die Testverpackung enthält CUDA 12.8.1 und Build-Werkzeuge;
+Debian-Host und Treiber werden nicht verändert. Build-Last ist auf 2 CPUs,
+8 GiB RAM und maximal zwei Compiler-Jobs begrenzt. Builds liegen unter
+`state/runtime`, werden nicht in Konfigurations-Backups dupliziert und bleiben
+bei Updates erhalten. Geprüfte Versionen können als Standard ausgewählt und
+zurückgeschaltet werden; das startet kein Modell.
+
+GET `/api/v1/runtime`, `/prerequisites`, `/releases`, `/log`; POST `/build`
+(revision, backend, jobs), `/cancel` ({}), `/activate` (build_id), `/rollback` ({}),
+jeweils unter `/api/v1/runtime`. Nur Administratorsitzungen sind zugelassen.
+Release-Quellen: https://github.com/ggml-org/llama.cpp/releases .
+
+Die feste VRAM-Reserve entfällt. Die Buildprüfung ermittelt die tatsächliche
+Unterstützung von `--fit`; modellbezogene Layer-/Kontextprognose wird über das unten beschriebene
+Fit-Werkzeug bereitgestellt. Modellstarts sind noch nicht angebunden. Keine erfundenen Schätzungen,
+keine absichtlichen OOM-Versuche und keine Eingriffe in produktive Worker.
+
+### Auto-Einpassung mit den bisherigen Routermodellen
+
+`llama-fit-params` wird mitgebaut. GET `/api/v1/runtime/references` liefert die
+am 28.09.2026 aus dem alten Router gelesenen Profile Fast/Medium/Large/Ultra/
+Uncensored. POST `/api/v1/runtime/fit` nimmt profile, context und slots entgegen.
+Die drei GGUF-Dateien werden einzeln und nur lesend in den Testcontainer
+eingebunden (`reference_models` im Entwicklungsmanifest). Keine Kopie der
+Gewichte, kein Zugriff auf Prompts oder Anwendungslogs.
+
+Das offizielle Fit-Werkzeug verwendet `no_alloc` für Modellgewichte und liefert
+eine Prognose anhand des aktuellen freien Speichers, q4_0-KV-Cache und explizitem
+Kontext/Slots. Die automatische Reserve beträgt als Sicherheitsregel 5 % des jeweiligen
+Gesamt-VRAM, mindestens 512 MiB. Karten mit weniger als 10 % freiem VRAM
+(mindestens 1 GiB) werden vor CUDA-Initialisierung aus der Prüfung ausgeschlossen.
+Diese Regeln sind Sicherheitsmargen, keine gemessene exakte Modellkapazität. Es findet kein OOM-Stresstest und kein Modellstart statt.
+Eine Prognose ist keine Garantie unter wechselnder Parallelbelegung. Der native
+Betrieb kann dieselben Dateien über DECK_REFERENCE_MODELS bereitstellen.
+
+Fit-Adapter: Das Upstream-Fit-CLI bietet die Serveroption `--kv-unified` nicht an.
+Deck setzt deshalb beim Build in `tools/fit-params/fit-params.cpp` vor der
+Backend-Initialisierung explizit `params.kv_unified = true`, entsprechend den
+bestehenden Profilen. Die Anpassung ist als `shared-kv-pool-v1` im Buildstand
+vermerkt; die eigentliche Fit-Berechnung bleibt upstream. Fehlt der erwartete
+Quellanker, bricht der Build ab, statt eine andere Semantik zu verwenden.
+
+Die Fit-Prognose gilt zunächst für das Textmodell. Vision-Projektoren und MTP
+der bisherigen Routerprofile sind nicht eingerechnet. Außerdem ersetzt sie keine
+RAM-/Lastprüfung eines späteren Worker-Starts im begrenzten Testcontainer.
+
+Verifikation: CUDA-Release b11229 (c2a9e1606807970f4ee3167bacd951699c89caea)
+für 86/120 erfolgreich gebaut. Medium, 160000 Kontext, zwei Slots: echte
+Fit-Prognose erfolgreich. Bei damaliger Parallelbelegung 0 GPU-Modelllayer;
+GPU-Rechenpuffer 1044 MiB, Host Modell 13635 MiB, Kontext 3111 MiB, Compute
+93 MiB. Das überschreitet das 8-GiB-RAM-Limit der Testinstanz und wird als
+nicht startbar markiert. Keine Modellgewichte allokiert, alle zuvor vorhandenen
+Container-Startzeiten unverändert. 46 Tests erfolgreich.
+
+Der verifizierte Erstbuild liegt in `state/runtime-verification`;
+`state/runtime/<Build-ID>` verweist intern darauf, damit seine Build-RPATHs
+erhalten bleiben. Beide Verzeichnisse gehören ausschließlich Deck und bleiben
+bei Updates bestehen. Künftige Builds entstehen direkt unter `state/runtime`.