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_en.md

@@ -882,7 +882,53 @@ typically `localhost/checkmk/check-mk-enterprise:2.3.0p23`) and writes it to
 sudo ./scripts/cmk-manage.sh up
 ```
 
-### 8.7 Checking what is in effect
+### 8.7 `CMK_IMAGE` versus `CMK_EDITION`/`CMK_VERSION`
+
+These three values have different jobs, and confusing them is a common
+mistake:
+
+| Value | Who reads it | What for |
+|---|---|---|
+| **`CMK_IMAGE`** | **compose and the systemd units** | the image that actually starts |
+| `CMK_EDITION` | only `cmk-manage.sh image …` | input for the downloader |
+| `CMK_VERSION` | only `cmk-manage.sh image …` | input for the downloader |
+
+`CMK_IMAGE` can **not** be derived from edition and version – depending on how
+you obtained it, the very same version looks completely different:
+
+```
+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               (loaded from a tarball)
+```
+
+So `CMK_IMAGE` records what is **actually there**, and it is written by
+`image pull`, `image download`, `image load` and `image use` – you normally
+never have to type anything there by hand.
+
+> **Consequence:** changing the edition or version does **not** start a
+> different release. Only `image pull` (or `download`/`load`) writes the result
+> to `CMK_IMAGE`, and only `up` recreates the container.
+
+To stop these from drifting apart unnoticed, the script compares the three
+values – in `image status`, in `status`, and in the settings menu right after
+the edition or version is changed:
+
+```
+[ 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"
+...
+    ./scripts/cmk-manage.sh image pull --edition enterprise --version 2.3.0-latest
+    ./scripts/cmk-manage.sh up
+```
+
+("CMK_IMAGE does not match the configured defaults / in use / configured … but
+the image contains …".) Images loaded from a tarball (`localhost/…`) count as
+consistent as long as name and tag match.
+
+### 8.8 Checking what is in effect
 
 ```bash
 ./scripts/cmk-manage.sh image status     # configured image + local images