release: v1.2.2 — pi 0.80.2 + mempalace 3.5.0, drop anyOf workaround

- Bump mempalace pin 3.4.0 -> 3.5.0: 3.5.0 carries the upstream fix for the
  top-level-anyOf diary_write schema (issue #1728 / PR #1717, merged
  2026-06-14). Verified against the published 3.5.0 wheel that mcp_server.py
  now advertises 'required: [agent_name]' with no root-level anyOf.
- Remove the Dockerfile.base perl workaround that stripped the anyOf from the
  installed mcp_server.py — obsolete now the fix is upstream.
- pi auto-resolves to npm latest (0.79.10 -> 0.80.2) at build.
- CHANGELOG v1.2.2.

CHANGELOG.md

@@ -11,6 +11,43 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 ---
 
+## v1.2.2 — 2026-06-24
+
+Patch release: pick up **pi `0.80.2`** (npm `latest`) and **mempalace `3.5.0`**,
+and drop the now-obsolete `diary_write` schema workaround — the upstream fix
+shipped.
+
+### Changed
+
+- **mempalace pin `3.4.0` → `3.5.0`.** mempalace 3.5.0 carries the upstream
+  fix for the top-level-`anyOf` `diary_write` schema
+  ([issue #1728](https://github.com/MemPalace/mempalace/issues/1728) /
+  [PR #1717](https://github.com/MemPalace/mempalace/pull/1717), merged
+  2026-06-14). The advertised schema is now `"required": ["agent_name"]` with
+  `entry`/`content` enforced at dispatch instead of via a root-level `anyOf`,
+  which Anthropic's tools API accepts. Verified against the published 3.5.0
+  wheel's `mcp_server.py` before removing the workaround.
+- **pi `0.79.10` → `0.80.2`**, auto-resolved from npm `latest` at build time
+  (no pin in the repo; CI's `resolve-versions` job fetches it).
+
+### Removed
+
+- **The `diary_write` top-level-`anyOf` workaround in `Dockerfile.base`.** The
+  `perl` patch that rewrote the installed `mcp_server.py` (needed while
+  mempalace 3.3.x/3.4.0 advertised a top-level `anyOf` that Anthropic rejects,
+  failing tool registration at session start) is gone, since 3.5.0 fixes it at
+  the source. Keep `MEMPALACE_VERSION` in lockstep with opencode-devbox.
+
+### Notes
+
+- Unrelated to this release: a *stalled* `mempalace-mcp` (e.g. a slow virtiofs
+  cold-open of `chroma.sqlite3`) surfaces as `mempalace-mcp not available`
+  because the `mempalace.ts` extension's per-request timeout kills the child
+  and flips `available=false` until pi is restarted — this is the 2026-06-13
+  stall-protection behaving as designed, not the `anyOf` bug.
+
+---
+
 ## v1.2.1 — 2026-06-22
 
 Patch release: close the fork/recall + mempalace **under-utilisation gap** in