Fix: Engine-Update lief ins Leere (falsches Skript gepinnt) + Text-file-busy

ROOT CAUSE: Die Unit pinnte MC_ENGINE_UPDATE_CMD=/usr/local/bin/update-llamacpp —
ein Alt-Skript aus der ROCm-Zeit, das den ROCm-Build nach /opt/llamacpp (totes
Rollback-Dir) zog statt des aktiven Vulkan-Builds nach /opt/llamacpp-vulkan. Es
endete mit 0 → Job "DONE", aber die aktive Engine blieb auf 9821. Mein
deploy/update-engine.sh lag dadurch komplett brach. Fix: Pin aus der Unit raus →
Backend nutzt den Default `sudo bash <repo>/deploy/update-engine.sh`.

Zusätzlich (vom User vermutet): mit geladenem Modell laeuft llama-server → die
Binary ist "Text file busy", in-place ueberschreiben scheitert. update-engine.sh
und update-swap.sh stoppen llama-swap jetzt VOR dem Austausch und starten danach,
mit robustem Fehlerpfad (set -uo statt -e, Service kommt immer zurueck, sonst
Rollback aus .bak).

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

deploy/mission-control-2.service

@@ -20,7 +20,10 @@ Environment=MC_CONFIG_PATH=/etc/llama-swap/config.yaml
 Environment=MC_MODELS_DIR=/srv/models
 # Geteiltes Gedächtnis = die bestehende v1-DB (Kontinuität bis/über Cutover).
 Environment=MC_MEMORY_DB=/srv/models/mission-control-memory.db
-Environment=MC_ENGINE_UPDATE_CMD=/usr/local/bin/update-llamacpp
+# KEIN MC_ENGINE_UPDATE_CMD-Override mehr: Das alte /usr/local/bin/update-llamacpp zog den
+# ROCm-Build nach /opt/llamacpp (totes Rollback-Dir) statt des aktiven Vulkan-Builds → Updates
+# liefen ins Leere ("DONE", aber nichts passierte). Ohne Override nutzt das Backend den Default
+# `sudo bash <repo>/deploy/update-engine.sh` (Vulkan, mit Backup/Stack-Check/Auto-Rollback).
 Restart=on-failure
 
 RestartSec=3