release(v1.12.0): pi 1.3.0, mempalace 3.11.0, pi-atelier v0.16.0

Every component at its newest upstream release; each pinned one audited
against this image before tagging, none breaking.

- ARG PI_VERSION 1.2.0 -> 1.3.0. No breaking-changes section. pi-agent-core,
  pi-tui and dist/core/extensions are byte-identical to 1.2.0. The only
  removed export (parseModelPattern, not index-exported) and pi-ai's dropped
  assistant-message-frame re-export have 0 consumers; all 54 runtime-imported
  names across the stack and /opt/fleet-pi resolve (negative control
  reported). With a copy of tor-ms22's ~/.pi/agent: pi -p exits 0 in 10 s,
  all extensions load, bridge 45 tools, /om:* and /studio offered, atelier
  paints in both renderers (-ne controls: none).
- ARG MEMPALACE_VERSION 3.10.0 -> 3.11.0. init --yes still writes
  config.json; a 3.10.0-built palace opens, searches and serves MCP under
  3.11.0, re-mines its convo file once, then skips it; stdio MCP 45 -> 47
  tools, none removed. research() removal: 0 callers. synlig hub stays
  3.10.0 (newer-client direction); upgrade notes in CHANGELOG.
- ARG PI_ATELIER_REF/VERSION v0.15.0 -> v0.16.0 (3b42825). Additive
  (keyValues rows, progress bars, two roles, meter background). Protocol
  and pi floor unchanged; fleet:todos panel renders a real todo on both
  versions; the meter-background escape tells the two arms apart.
- Base rebuilds anyway, so BASE_REBUILD_DATE marker refreshed (uv 0.13.1,
  gitea-mcp 1.9.0, Node 24.22.0 re-resolve).
- CHANGELOG: Unreleased -> v1.12.0 — 2026-10-18. README pin table (and
  "Three" -> "Four" components), sanity-check example; DOCKER_HUB.md's stale
  "29 mempalace_* tools".

Local gates: check-doc-drift rc 0 (check 9 names pi, mempalace, atelier,
pi-extensions), lint-shell, check-workflow-shell, test-link-pi-models
13/13, test-link-pi-extensions 16/16, directive guard, skill floor.

Dockerfile.variant

@@ -289,7 +289,35 @@ ARG USER_NAME=developer
 # none); a copy of tor-ms22's real ~/.pi/agent (all packages, pi-extensions
 # 750b2a8) starts with the same [Extensions] list as on 1.1.0 and no
 # [Extension issues]; `pi -p` answers PONG via ERDC in 1.0 s, Bedrock in 5.2 s.
-ARG PI_VERSION=1.2.0
+#
+# v1.12.0: 1.2.0 -> 1.3.0 (npm latest, 2026-10-15). MEASURED 2026-10-18 on
+# tor-ms22 from an isolated npm prefix, against the 1.2.0 tarballs unpacked
+# side by side:
+#   1. NO `### Breaking Changes` section in 1.3.0. Behaviour changes, none of
+#      which reaches us: `--model`/`enabledModels` resolve a bare id across
+#      providers by credentials (ours are all `amazon-bedrock/...`, and
+#      pi-fork's effortProfiles name a provider); resumed sessions restore
+#      their active tools; thinking from another model is dropped on a model
+#      switch; `kimi-coding` base-URL overrides need `/v1` (not used).
+#   2. pi-agent-core and pi-tui 1.2.0 -> 1.3.0: dist BYTE-IDENTICAL (tree
+#      hashes 6a2819f6 / 92eecf92, 24 / 184 files), and so is pi-coding-agent's
+#      dist/core/extensions. So obsmem's turn cap (agent-core) and atelier's
+#      painting (pi-tui) cannot have moved there; atelier's internals
+#      TuiMainScreen / renderLayoutFrame are in the same number of dist files.
+#   3. Public API: the only removed export in any .d.ts is
+#      `parseModelPattern` (model-resolver, never re-exported from the package
+#      index), and pi-ai dropped its `assistant-message-frame` re-export. 0
+#      consumers of either. All 54 runtime-imported names across pi-toolkit,
+#      pi-extensions, pi-fork, obsmem, pi-studio, pi-atelier, mempalace-toolkit
+#      and /opt/fleet-pi resolve in 1.3.0 (control: an injected fake name is
+#      reported missing).
+#   4. engines.node is still `>=22.19.0`; internal deps are now exact pins.
+# Exercised before tagging, with a copy of tor-ms22's real ~/.pi/agent:
+# `pi -p` exits 0 in 10 s (1.2.0: 9 s), nothing on stderr; the TUI loads every
+# extension with no [Extension issues], the bridge registers its 45 tools,
+# /om:status, /om:view and the /studio commands are offered, and atelier
+# paints ACTIVITY/READY/TOOLS in both renderers (controls with -ne: none).
+ARG PI_VERSION=1.3.0
 ARG PI_TOOLKIT_REF=main
 ARG PI_EXTENSIONS_REF=main
 # Repo URLs default to the canonical gitea origin but are overridable so a
@@ -416,9 +444,20 @@ ARG PI_ATELIER_REPO=https://github.com/michaelmjhhhh/pi-atelier.git
 # renderers on pi 1.1.0 before tagging (see the PI_VERSION note).
 # v1.11.2: unchanged (still the newest tag); painted in both renderers on
 # pi 1.2.0 before tagging.
-ARG PI_ATELIER_REF=v0.15.0
+# v1.12.0: v0.15.0 -> v0.16.0 (3b42825, 2026-10-15). Additive: contributed
+# panels may send label/value rows with an optional progress bar (`keyValues`;
+# plain `rows` stay the fallback) and two new roles, and the context meter
+# loses its hard-coded dark background. Protocol unchanged (channel
+# `pi-atelier:sidebar-panels`, version 1, 24 rows, 160 chars), peer floor
+# unchanged (pi >=0.84.0), still zero runtime dependencies. On pi 1.3.0 it
+# paints in both renderers, and the fleet's contributed `fleet:todos` panel
+# (/opt/fleet-pi/fleet-todos-panel.ts, plain rows) shows a todo written in a
+# real turn, as on v0.15.0. The v0.15.0 arm still draws the old meter
+# background (48;2;48;53;56) and the v0.16.0 arm does not, so the arms ran the
+# code they claim.
+ARG PI_ATELIER_REF=v0.16.0
 # Human-readable tag PI_ATELIER_REF was resolved from; recorded as a label.
-ARG PI_ATELIER_VERSION=v0.15.0
+ARG PI_ATELIER_VERSION=v0.16.0
 
 RUN set -e && \
     # git_fetch_ref: clone-equivalent helper that accepts EITHER a branch name