docs(v1.9.4): the client/server skew is narrower than the release commit said

e3b38cd named "the feeder against the 3.9.0 hub" as the one path to exercise
before tagging, on the reasoning that 3.10.0's CLI writes now follow the daemon
write-routing policy. That was a reading of the mempalace changelog, not a
measurement of this image's feeder. Measured now:

  mempalace-pi-session in remote mode (MEMPALACE_REMOTE_URL set, which is how
  every fleet devbox runs) stages transcripts locally in python, rsyncs them to
  the hub host, and calls the hub's own `mempalace_mine` MCP tool over HTTP
  (run_remote_mine). The local `mempalace` CLI is required only in local mode
  (line 475) and invoked only on the local branch (line 1029). With a PATH shim
  logging every `mempalace` invocation, a 47-session `--dry-run` from this
  container logged ZERO calls; the shim's positive control logged one. The pi
  extension likewise speaks HTTP to the hub and spawns no local mempalace-mcp.

So the 3.10.0 CLI never runs against the 3.9.0 hub from this image. In remote
mode the client pin touches first-run `mempalace init` and the on-disk layout,
nothing else -- which is exactly what the ENV MEMPALACE_CONFIG_DIR change is
for. Both the Dockerfile.base comment and the CHANGELOG paragraph now say so,
and the "Still open" item becomes the thing that is actually unmeasured: a
first-boot acceptance of the built image from an empty ~/.mempalace volume.

Gates re-run on this tree: check-doc-drift.sh rc=0, lint-shell.sh rc=0,
hadolint 2.15.1 rc=0. lint.yml for e3b38cd: run 693, completed, success.

CHANGELOG.md

@@ -89,10 +89,15 @@ provenance), `limit`/`offset` on `kg_timeline`, `last_modified` on drawers.
 `Dockerfile.base` sequencing comment had claimed for two releases (corrected in
 this commit). Client and server are level today; this image reintroduces skew
 until synlig runs `uv tool upgrade mempalace` and restarts the unit. That is the
-step that lights up the server-side changes above. Skew-relevant meanwhile: 3.10.0
-CLI writes follow the daemon write-routing policy (`direct`/`prefer`/`require`),
-so the feeder (`mempalace-pi-session`, 3.10.0 client) against the 3.9.0 hub is
-the one path to exercise on the built image before tagging — see *Still open*.
+step that lights up the server-side changes above. The skew meanwhile is narrower
+than the release commit's message claimed: the pi extension speaks HTTP to the hub
+(no local `mempalace-mcp` is spawned), and the feeder in remote mode stages
+locally in python, rsyncs, and calls the hub's own `mempalace_mine` tool.
+Measured with a PATH shim in front of `mempalace`: a 47-session
+`mempalace-pi-session --dry-run` from this container made **zero** local CLI calls
+(the shim's positive control logged one). So 3.10.0's new CLI write-routing
+policy never runs against the hub from this image; in remote mode the client pin
+touches first-run `mempalace init` and the on-disk layout, nothing else.
 
 ### pi-atelier v0.10.1 → v0.10.3 (`734258b` → `ed3837b`)
 
@@ -134,12 +139,13 @@ a stop that #83 makes moot.
 
 ### Still open
 
-- **Feeder against the 3.9.0 hub** — run `mempalace-pi-session` from the built
-  v1.9.4 image against synlig (dry-run first) before tagging. The palace-path
-  adaptation was measured with the wheel, not the image; the recreate acceptance
-  on the first device should confirm `~/.mempalace/palace/chroma.sqlite3` still
-  passes in `recreate-sanity-check.sh` and that `~/.config/mempalace` does not
-  appear.
+- **First-boot acceptance on the built image** — the palace-path adaptation was
+  measured with the wheel, not the image. Start a throwaway container from the
+  published v1.9.4 with an *empty* `~/.mempalace` volume and confirm the
+  entrypoint's `mempalace init` lands `config.json` there, that
+  `~/.config/mempalace` does not appear, and that `MEMPALACE_CONFIG_DIR` is in
+  the container environment. On a real device the recreate checklist's
+  `recreate-sanity-check.sh` should keep passing `~/.mempalace/palace/chroma.sqlite3`.
 - **synlig upgrade to 3.10.0** after v1.9.4 is accepted on one device:
   `uv tool upgrade mempalace`, restart `mempalace-serve.service`, verify one
   search and one `event_list`.

Dockerfile.base

@@ -590,10 +590,15 @@ ARG INSTALL_MEMPALACE=true
 # `get_collection()` refuses unknown collection names (library callers only).
 # MCP tool-schema review, as always: no tool removed or renamed; additive
 # fields on search results (filed_at / content_date provenance), `limit` /
-# `offset` on kg_timeline, `last_modified` on drawers. Skew-relevant while
-# synlig stays on 3.9.0: CLI writes now follow the daemon write-routing policy
-# (direct / prefer / require) — the feeder against a 3.9.0 hub is the one
-# thing to exercise before tagging.
+# `offset` on kg_timeline, `last_modified` on drawers. Skew while synlig stays
+# on 3.9.0 is narrower than it looks: the pi extension speaks HTTP to the hub
+# (no local mempalace-mcp is spawned), and the feeder in remote mode stages
+# locally in python, rsyncs, and calls the hub's own `mempalace_mine` tool.
+# Measured 2026-09-22 with a PATH shim in front of `mempalace`: a 47-session
+# `mempalace-pi-session --dry-run` made ZERO local CLI calls (the shim's
+# positive control logged one). So 3.10.0's new CLI write-routing policy never
+# runs against the hub from this image; the client pin touches first-run
+# `mempalace init` and the on-disk layout, nothing else in remote mode.
 ARG MEMPALACE_VERSION=3.10.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