fix(cli): stop --print-effective-config from starting a container

argparse requires exactly one action, so the documented diagnostic form
`--print-effective-config --config … --start` never took the early-return
branch in main.run(): it printed the resolved config and then executed a
real do_start(), silently replacing a running container with the [default]
model. README, installation guide and manual all recommended that form.

Make it an action in the mutually exclusive group. It can no longer be
combined with --start/--check/--stop/--change/--chat (argparse error,
exit 2), and it skips the docker_available() check, so it now really is
the offline config check the docs promise. --dry-run remains a modifier
and still requires a reachable daemon.

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

docs/SECURITY_AND_OPERATIONS.md

@@ -258,22 +258,29 @@ keinen vermeidbaren Ausfall verursacht.
 
 ## 6. `--dry-run` und `--print-effective-config` als Sicherheitswerkzeuge
 
-- `--print-effective-config` gibt die vollständig aufgelöste Konfiguration
-  (Server- und Prompt-Konfiguration) als JSON aus, **bevor** irgendeine
-  Docker- oder HTTP-Aktion ausgeführt wird. Damit lässt sich prüfen, welche
-  Werte aus welcher Quelle (Defaults/[default]/[model.*]/CLI) tatsächlich
-  gewonnen haben, ohne einen Container anzufassen.
+- `--print-effective-config` ist eine **eigene Aktion** in der
+  Mutually-Exclusive-Gruppe: sie gibt die vollständig aufgelöste Konfiguration
+  (Server- und Prompt-Konfiguration) als JSON aus und beendet sich. Damit lässt
+  sich prüfen, welche Werte aus welcher Quelle (Defaults/[default]/[model.*]/CLI)
+  tatsächlich gewonnen haben, ohne einen Container anzufassen.
+
+  Bis einschließlich 0.1.0 war dies ein *Flag*. Da argparse immer eine Aktion
+  verlangt, führte `--print-effective-config --start` die Konfigurationsausgabe
+  **und anschließend einen echten `do_start()`** aus — der einen laufenden
+  Container stillschweigend ersetzte. Die Kombination ist jetzt ein
+  argparse-Fehler (Exit-Code 2).
 - `--dry-run` (in Kombination mit `--start`/--change`) zeigt den vollständig
   zusammengesetzten `docker run`-Befehl (Shell-quotiert zur Anzeige) an,
   **ohne** ihn auszuführen. Empfohlen vor jeder Änderung an einer
   Produktionskonfiguration, insbesondere nach Anpassungen an
   `llama.cpp.config`.
 
-Beide Flags erfordern **keinen** erreichbaren Docker-Daemon für ihre reine
-Ausgabe — `main.run()` prüft `docker_available()` derzeit vor der
-Konfigurationsauflösung; auf einem Host ganz ohne Docker (z. B. zur reinen
-Konfigurationsvalidierung) schlägt der Aufruf entsprechend mit einer
-expliziten Fehlermeldung fehl statt still falsche Annahmen zu treffen.
+`--print-effective-config` erfordert **keinen** erreichbaren Docker-Daemon;
+`main.run()` überspringt die `docker_available()`-Prüfung für diese Aktion. Für
+`--dry-run` gilt das **nicht**: es ist ein Modifikator von `--start`/`--change`,
+und die Docker-Prüfung läuft vor der Konfigurationsauflösung. Auf einem Host ganz
+ohne Docker schlägt `--start --dry-run` daher mit einer expliziten Fehlermeldung
+fehl, statt still falsche Annahmen zu treffen.
 
 ## 7. Betriebsmodell auf einem dedizierten GPU-Host