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).

CHANGELOG.md

@@ -75,6 +75,22 @@ would fire on nothing wrong), and a "documented tag exists on Hub" check
 (check 8 already SKIPs a missing tag by name, and a hard fail would
 misreport the window between tagging and publish).
 
+**Blind spot closed while it was free: `se.jordbo.pi-devbox.mempalace-version`.**
+No label recorded the palace pin, so check 9 could not see a `MEMPALACE_VERSION`
+bump — checks 1–3 keep README's pin table consistent, but nothing required a
+CHANGELOG line for the one component whose skew against the shared central
+palace is fleet-wide. The label is set in `Dockerfile.base` next to the `ARG`
+that defines it and **inherited** by both variants: no second copy of the pin to
+drift, no build-arg to plumb through four variant call sites, and it states the
+pin of the base the image *actually* built on — the question that matters when
+`base-decide` cache-hits an older base. Intent, like every label here; the
+manifest's `mempalace_version` stays the ground truth, and `smoke-test.sh` now
+asserts label == installed binary (the one way they diverge is a base built with
+`INSTALL_MEMPALACE=false`, or an install that resolved off-pin). Until a release
+carries the label, check 9 reports that component as a counted SKIP, not OK;
+costs nothing extra because this Unreleased already forces a base rebuild
+(`rootfs/` skill floor).
+
 ---
 
 **The rule "use `pi-task`, not `fork`, for a brief that carries a prohibition" was