fix: automate verified Unraid update workflows

docs/QWEN_OPERATOR_CONTEXT.md

@@ -242,16 +242,23 @@ WireGuard-Adresse sind alle Fach-MCPs direkt erreichbar.
 | ARR | Sonarr/Radarr, Indexersuche, kontrollierte Grabs | Lesen; Schreiben nur Preview/Approval |
 | Navidrome | Bibliothek, Empfehlungen, Playlists/Favoriten | eigener Benutzer; gezielt aktivieren |
 | MUA read-only | Host-, Docker-, Array-, Netzwerk- und Logdiagnose | automatischer Standard |
-| MUA/Admin | eng definierte Unraid-Verwaltung | bewusst aktivieren |
+| MUA/Admin | eng definierte Unraid-Verwaltung | bei ausdrücklich verlangter Änderung automatisch zusätzlich bereitgestellt |
 
 Für automatische Unraid-Diagnose existiert in Open WebUI zusätzlich
 `mua-readonly-local`. Diese Verbindung nutzt denselben lokalen MUA-Endpunkt,
 blendet aber Start/Stop, Installation, Änderungen und die freie Root-Shell
-serverseitig in Open WebUI aus. Die vollständige Verbindung `mua` wird niemals
-automatisch bereitgestellt.
+serverseitig in Open WebUI aus. Die vollständige Verbindung `mua` wird nur bei
+einer in der aktuellen Nachricht ausdrücklich verlangten Unraid-Änderung
+zusätzlich bereitgestellt.
 Es gibt keinen zweiten GraphQL-basierten Unraid-MCP. Schlägt MUA fehl, darf
 nicht auf GraphQL ausgewichen oder dessen API eigenmächtig aktiviert werden.
 
+Für mehrere Docker-Image-Updates ist
+`unraid_docker_update_verified_batch` verbindlich. Es ersetzt wiederholte
+Einzelaufrufe, vergleicht echte Image-IDs, erhält laufend/gestoppt und
+verifiziert das Ergebnis im selben Aufruf. Details stehen in
+`docs/UNRAID_AUTOMATIC_UPDATE_WORKFLOW.md`.
+
 Der vorhandene Deemix-Dienst läuft auf Unraid und ist als externe Abhängigkeit
 im Diensteverzeichnis eingetragen. Für ein Deemix-MCP wird standardmäßig nur
 ein Relay auf Athena gebaut; ein zweites Deemix-Backend erfordert einen