Dockerfile.base: LABEL se.jordbo.pi-devbox.mempalace-version, inherited by both variants

Closes the blind spot check 9 (cb6d9e5) named: no label recorded the palace
pin, so a MEMPALACE_VERSION bump — the one component whose skew against the
shared central palace is fleet-wide — could ship without a CHANGELOG line.

In Dockerfile.base, not Dockerfile.variant, deliberately: the value sits next
to the ARG that defines it (a copy in the variant is one more pin able to
drift); labels are inherited by every image built FROM the base, so no
build-arg to plumb through the variant's four call sites; and inheritance
means the label states the pin of the base the image ACTUALLY built on,
which is the question when base-decide cache-hits an older base. Both
mechanisms measured on the published v1.9.2 config blob rather than assumed:
maintainer + image.source (set only in Dockerfile.base) are present on the
variant image, and pi-version=0.85.1 is an ARG expanded inside a LABEL.

Intent, like every se.jordbo.pi-devbox.* label; the manifest's
mempalace_version (read from the installed binary) stays the ground truth,
and smoke-test.sh now asserts label == installed core — the one way they
diverge is a base built with INSTALL_MEMPALACE=false or an off-pin install,
both invisible to a label-only check.

check-doc-drift check 9 gains the component (literal, against
ARG MEMPALACE_VERSION in Dockerfile.base); the label-key rule generalises to
"names ending in -version are the label itself". Until a release carries the
label it reports a counted SKIP, not OK — measured: "v1.9.2 carries no
se.jordbo.pi-devbox.mempalace-version label", summary says 1 SKIPPED.

Costs nothing extra: this Unreleased already forces a base rebuild
(50153e6 rootfs/ skill floor). check-base-hash unchanged (no new *_REF).

Dockerfile.base

@@ -552,6 +552,20 @@ ARG INSTALL_MEMPALACE=true
 # so they stay dark until synlig is redeployed — a client bump alone cannot
 # light them up.
 ARG MEMPALACE_VERSION=3.9.0
+# Recorded as a label HERE, not in Dockerfile.variant, for three reasons: the
+# value lives next to the ARG that defines it (a second copy in the variant
+# would be one more pin able to drift, which is the class check-doc-drift.sh
+# exists to catch); labels are inherited by every image built FROM this one, so
+# both variants carry it with no build-arg to plumb through four call sites;
+# and inheritance means the label states the pin of the base the variant
+# ACTUALLY built on — which is the question when base-decide cache-hits an
+# older base. Like every se.jordbo.pi-devbox.* label this records INTENT; the
+# ground truth is /etc/pi-devbox/build-manifest.json's mempalace_version, read
+# from the installed binary, and scripts/smoke-test.sh asserts the two agree.
+# check-doc-drift.sh check 9 reads this off the last published image so that a
+# pin bump must be named in the CHANGELOG — until this label ships, that
+# component reports SKIP (label absent on the published release), not OK.
+LABEL se.jordbo.pi-devbox.mempalace-version="${MEMPALACE_VERSION}"
 ENV UV_TOOL_DIR=/opt/uv-tools
 ENV UV_TOOL_BIN_DIR=/usr/local/bin
 RUN if [ "${INSTALL_MEMPALACE}" = "true" ]; then \