CMK_IMAGE gegen CMK_EDITION/CMK_VERSION pruefen

Anlass war die Frage, wozu CMK_IMAGE neben Edition und Version
ueberhaupt noch noetig ist. Antwort: es ist der einzige Wert, den
compose und die systemd-Units lesen. Edition und Version sind reine
Vorgaben fuer den Downloader und wirken erst ueber "image pull".
Ableiten laesst sich CMK_IMAGE nicht, weil dieselbe Version je nach
Bezugsweg voellig anders heisst - docker.io/..., registry.checkmk.com/...
oder localhost/... bei einem aus dem Tarball geladenen Image.

Daraus folgt eine Falle, die bisher nirgends auffiel: wer Edition auf
"enterprise" stellt, CMK_IMAGE aber auf dem Raw-Image stehen laesst,
betreibt weiter Raw. Genau dieser Zustand kam in der Praxis vor.

image_consistency_check vergleicht deshalb Name und Tag von CMK_IMAGE
mit Edition und Version und meldet Abweichungen - in "image status",
im allgemeinen "status" und im Einstellungsmenue direkt nach dem
Aendern von Edition oder Version, dort gleich mit dem Angebot, das
Image zu holen. Aus Tarballs geladene Images (localhost/...) gelten
als stimmig, solange Name und Tag passen; die Editionsaliase werden
beruecksichtigt, "pro" passt also zu check-mk-enterprise.

Die Beschriftungen in den Einstellungen sagen jetzt, wer was tut:
  CMK_IMAGE    VERWENDETES Image - setzt "image pull"
  CMK_EDITION  Edition (nur Vorgabe, wirkt ueber "image pull")
  CMK_VERSION  Version (nur Vorgabe, wirkt ueber "image pull")

Vier Faelle geprueft: abweichende Edition, abweichende Version,
stimmiger Zustand und aus Tarball geladenes Image.

Dokumentiert als Abschnitt 8.7 in beiden Sprachfassungen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -876,7 +876,54 @@ ihn als `CMK_IMAGE` in die `.env` ein. Danach:
 sudo ./scripts/cmk-manage.sh up
 ```
 
-### 8.7 Nachsehen, was gilt
+### 8.7 `CMK_IMAGE` gegenüber `CMK_EDITION`/`CMK_VERSION`
+
+Diese drei Werte haben unterschiedliche Aufgaben, und das ist eine häufige
+Verwechslung:
+
+| Wert | Wer liest ihn | Wozu |
+|---|---|---|
+| **`CMK_IMAGE`** | **compose und die systemd-Units** | das Image, das tatsächlich gestartet wird |
+| `CMK_EDITION` | nur `cmk-manage.sh image …` | Vorgabe für den Downloader |
+| `CMK_VERSION` | nur `cmk-manage.sh image …` | Vorgabe für den Downloader |
+
+`CMK_IMAGE` lässt sich **nicht** aus Edition und Version ableiten – je nach
+Bezugsweg sieht dieselbe Version völlig anders aus:
+
+```
+docker.io/checkmk/check-mk-raw:2.3.0-latest                 (Docker Hub)
+registry.checkmk.com/enterprise/check-mk-enterprise:2.3.0p9 (Registry)
+localhost/checkmk/check-mk-enterprise:2.3.0p9               (aus Tarball geladen)
+```
+
+Deshalb hält `CMK_IMAGE` fest, was **wirklich vorhanden ist**, und wird von
+`image pull`, `image download`, `image load` und `image use` gesetzt – von Hand
+muss man dort normalerweise nichts eintragen.
+
+> **Daraus folgt:** Edition oder Version zu ändern, startet **keine** andere
+> Ausgabe. Erst `image pull` (bzw. `download`/`load`) schreibt das Ergebnis
+> nach `CMK_IMAGE`, und erst `up` erstellt den Container neu.
+
+Damit das nicht unbemerkt auseinanderläuft, prüft das Skript die drei Werte
+gegeneinander – in `image status`, in `status` und im Einstellungsmenü direkt
+nach dem Ändern von Edition oder Version:
+
+```
+[ WARN ] CMK_IMAGE passt nicht zu den eingestellten Vorgaben.
+
+  verwendet wird : docker.io/checkmk/check-mk-raw:2.3.0-latest
+  Edition        : eingestellt "enterprise", im Image steckt "raw"
+
+Compose und die systemd-Units verwenden ausschliesslich CMK_IMAGE.
+...
+    ./scripts/cmk-manage.sh image pull --edition enterprise --version 2.3.0-latest
+    ./scripts/cmk-manage.sh up
+```
+
+Aus einem Tarball geladene Images (`localhost/…`) gelten dabei als stimmig,
+solange Name und Tag passen.
+
+### 8.8 Nachsehen, was gilt
 
 ```bash
 ./scripts/cmk-manage.sh image status     # konfiguriertes + lokale Images