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
+step that lights up the server-side changes above. The skew meanwhile is narrower
-CLI writes follow the daemon write-routing policy (`direct`/`prefer`/`require`),
+than the release commit's message claimed: the pi extension speaks HTTP to the hub
-so the feeder (`mempalace-pi-session`, 3.10.0 client) against the 3.9.0 hub is
+(no local `mempalace-mcp` is spawned), and the feeder in remote mode stages
-the one path to exercise on the built image before tagging — see *Still open*.
+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
+- **First-boot acceptance on the built image** — the palace-path adaptation was
-  v1.9.4 image against synlig (dry-run first) before tagging. The palace-path
+  measured with the wheel, not the image. Start a throwaway container from the
-  adaptation was measured with the wheel, not the image; the recreate acceptance
+  published v1.9.4 with an *empty* `~/.mempalace` volume and confirm the
-  on the first device should confirm `~/.mempalace/palace/chroma.sqlite3` still
+  entrypoint's `mempalace init` lands `config.json` there, that
-  passes in `recreate-sanity-check.sh` and that `~/.config/mempalace` does not
+  `~/.config/mempalace` does not appear, and that `MEMPALACE_CONFIG_DIR` is in
-  appear.
+  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
+# `offset` on kg_timeline, `last_modified` on drawers. Skew while synlig stays
-# synlig stays on 3.9.0: CLI writes now follow the daemon write-routing policy
+# on 3.9.0 is narrower than it looks: the pi extension speaks HTTP to the hub
-# (direct / prefer / require) — the feeder against a 3.9.0 hub is the one
+# (no local mempalace-mcp is spawned), and the feeder in remote mode stages
-# thing to exercise before tagging.
+# 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