release(v1.11.1): pi 1.2.0; CI builds the pinned pi-obsmem SHA

- pi 1.1.0 -> 1.2.0, audited on tor-ms22 from an isolated prefix: none of
  the four breaking changes reaches the image (3 before_agent_start
  handlers checked, no triggerTurn user, pi-studio themes load); agent-core
  dist byte-identical; turn cap N=19 honoured; atelier paints in both
  renderers; obsmem /om:* registered; real-config startup clean.
- resolve-versions reads ARG PI_OBSMEM_REF from Dockerfile.variant instead
  of resolving obsmem master (which overrode the pin as --build-arg),
  requires a 40-char SHA, and warns when master moves past the pin. Block
  tested in isolation: real pin, short/branch/missing pin, older pin,
  GitHub unreachable.
- CHANGELOG: Unreleased -> v1.11.1 — 2026-10-14. README pin table,
  BASE_REBUILD_DATE marker (base rebuilds anyway), stale VENDORED.md pointer.

CHANGELOG.md

@@ -11,17 +11,47 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 ---
 
-## Unreleased
+## v1.11.1 — 2026-10-14
 
-### Components that move with the next build
+Patch release. Headlines: **pi 1.2.0**, **`pi -p` returns in seconds** on a
+devbox instead of idling for five minutes (mempalace-toolkit), **MCP servers use
+pi's built-in support** (pi-extensions' `mcp-loader.ts` is retired), and **CI
+now builds the pinned pi-observational-memory commit** instead of whatever its
+`master` is that day. Unchanged upstream, re-checked 2026-10-14:
+pi-observational-memory `022da5e`, pi-atelier `v0.15.0`, pi-studio `v0.9.63`,
+pi-fork `e69725c`, pi-toolkit `3760d90`, mempalace `3.10.0`, Node 24 (v24.21.0
+LTS). The skillset moved (`96b840e` → `1e02b44`), but the vendored mempalace
+`SKILL.md` is byte-identical, so the snapshot is not refreshed. The base image is
+rebuilt (the rootfs skill floor and the mempalace-toolkit ref both changed), so
+the base tools pinned to `latest` re-resolve too.
 
-| Component | Baked in v1.11.0 | Next build | Why |
+### Components that move with this release
+
+| Component | Baked in v1.11.0 | v1.11.1 | Why |
 |---|---|---|---|
+| **pi** | `1.1.0` | **`1.2.0`** | audited, see *Changed* below |
 | pi-extensions | `a88fa99` | **`750b2a8`** (or later: CI resolves `main` at build time) | `mcp-loader.ts` retired; `install.sh` prunes stale links (below) |
 | mempalace-toolkit | `975ab92` | **`d5a03f4`** (or later) | `pi -p` returns in seconds: `2f0edf5` clears the feed's leftover 5-min timer, `f590a3a` skips the feed in print/JSON mode, and `d5a03f4` skips the wake-up and mailbox poll there too (below). Also `a30af61`: the bridge's `RemoteMcpClient` is now the only copy, and `scripts/check-mcp-client-sync.sh` is removed (comment/README only) |
 
 ### Fixed
 
+- **The pi-observational-memory pin now binds CI builds** (v1.11.0's known
+  issue). `resolve-versions` resolved the repo's `master` and passed it as
+  `--build-arg PI_OBSMEM_REF`, which overrides the Dockerfile's pinned default,
+  so CI baked the pin only while `master` happened to equal it (v1.9.5, v1.10.2,
+  v1.11.0). It now reads the pin from `Dockerfile.variant`, the way pi-atelier's
+  tag is read. It refuses anything but a full 40-char SHA, and prints a
+  `::warning::` with the compare link when `master` has moved past the pin. The
+  pin stays an untagged `master` commit on purpose. Upstream tags rarely (the
+  newest tag is still 3.1.4) and lands what pi needs on `master`: #83, the
+  migration to pi 0.87's `finishTurn`, never reached a tag. Its
+  `peerDependencies` are `*`, so a mismatch with pi fails silently at runtime.
+  Adopting a newer `master` is now a deliberate one-line bump, after the
+  turn-cap probe. The new step was run on its own against six inputs: the real
+  pin gives `022da5e` and no warning; a short SHA, `master` or a missing ARG
+  fails; an older pin gives that SHA plus the warning; GitHub unreachable gives
+  the pin and no warning. The workflow's pipeline comment, which still said pi
+  resolves from npm `latest`, is corrected too.
 - **`pi -p` on a devbox no longer sits idle for five minutes after
   answering.** It printed its answer, then held the terminal until a timer
   ran out: the feed's 300 s mine deadline (mempalace-toolkit `mempalace.ts`).
@@ -40,9 +70,9 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
   feed for a device that only runs `pi -p`. pi 1.0.0 behaved the same, so it
   predates v1.11.0. `pi-task` and `fork` children run `--no-extensions` and
   were never affected. `scripts/test-feed-exit.sh` in mempalace-toolkit pins
-  both changes, and each change's pre-fix source fails it. Until the next
-  build, scripts that call `pi -p` on a devbox should keep their `timeout` or
-  set `MEMPALACE_FEED=0`.
+  both changes, and each change's pre-fix source fails it. On images before
+  v1.11.1, scripts that call `pi -p` should keep their `timeout` or set
+  `MEMPALACE_FEED=0`.
 - **`pi -p` no longer gets the palace wake-up.** In print and JSON mode the
   mempalace bridge now skips the wake-up injection and the mid-session mailbox
   poll (mempalace-toolkit `d5a03f4`). The injection is status, diary, and the
@@ -57,6 +87,38 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 ### Changed
 
+- **pi `1.1.0` → `1.2.0`.** Audited 2026-10-14 on tor-ms22 from an isolated npm
+  prefix, by the same method as v1.11.0. 1.2.0 has four breaking changes, and
+  none reaches this image:
+  - `before_agent_start` also fires for runs started by
+    `pi.sendMessage(…, { triggerTurn: true })`, and its event is a union on
+    `messageType`. `systemPrompt` is on both members. Of the three handlers in
+    the image, ssh-controlmaster reads only `systemPrompt`, and aws-sso and
+    mempalace read no event field. Nothing in the image uses `triggerTurn`.
+  - The session counts as busy while a run starts, so `pi.sendUserMessage()`
+    then needs `deliverAs`. aws-sso already passes it. mempalace's
+    `/mempalace-diary` is a command, so it runs while pi is idle.
+  - Themes are schema-validated at startup, and the schema moved to `pi.dev`.
+    pi-studio's themes still name the old URL, but they load and apply on 1.2.0
+    with no warning.
+  - `pi mcp list --json` reports `resources: true` instead of counts. Nothing
+    here parses it.
+
+  Measured on 1.2.0. pi-agent-core's dist is byte-identical to 1.1.0's. The
+  turn-cap probe ran 19 turns uncapped and stopped at exactly 3 with
+  `maxTurns=3`. atelier paints in both renderers, with controls at 0/3.
+  pi-observational-memory registers `/om:status` and `/om:view`. A copy of
+  tor-ms22's real `~/.pi/agent` starts with the same extension list as on 1.1.0
+  and no extension issues. `pi -p` answers in 1.0 s through ERDC and 5.2 s
+  through Bedrock. One change reaches scripts: `pi -p` now exits 1 when the
+  reply was cut off at the model's output limit. That is text mode only;
+  `pi-task` and `fork` run `--mode json`. The first start after the upgrade
+  shows 1.2.0's What's New once. Read from the code, not reproduced: pi-studio
+  marks pi busy on `agent_start`, which 1.2.0 fires after the session already
+  counts as busy. A Studio request sent in that gap (the `before_agent_start`
+  handlers) gets pi's "Agent is already processing" error instead of Studio's
+  own "pi is busy". Before 1.2.0 the same request started a second run that
+  failed, so retrying is the answer either way.
 - **MCP servers now use pi's built-in MCP support; pi-extensions'
   `mcp-loader.ts` is retired.** pi has shipped MCP as a built-in extension
   (`builtin:mcp`) since 0.99.0: servers go in `~/.pi/agent/mcp.json` or are
@@ -88,10 +150,12 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 - **Vendored `pi-extensions` skill floor refreshed** to pi-extensions `750b2a8`.
   `check-skill-floor.sh` went red on the retirement commit and is green again.
   The skill now says MCP servers are the built-in's, not an extension. Because
-  `rootfs/` is in the base hash, the next tag rebuilds the base.
+  `rootfs/` is in the base hash, this release rebuilds the base.
 - DOCKER_HUB.md's pi-extensions list was three releases stale (`mcp-loader`
   listed; `task`, `fork-gate`, `secret-guard`, `aws-sso` missing). It now lists
-  the 10 that ship and has an MCP line.
+  the 10 that ship and has an MCP line. The vendored skills' `VENDORED.md`
+  pointed at "the Unreleased CHANGELOG entry", which had been stale since
+  v1.8.8; it now names v1.8.8.
 
 ## v1.11.0 — 2026-10-12