fix(base): work around mempalace diary_write top-level anyOf

Anthropic's tools API rejects top-level anyOf/oneOf/allOf in
input_schema. Mempalace 3.3.x/3.4.0 advertise diary_write with
`anyOf: [{required:[entry]}, {required:[content]}]`, breaking pi
on first prompt with:

  tools.<n>.custom.input_schema: input_schema does not support
  oneOf, allOf, or anyOf at the top level

Patch the installed mcp_server.py after `uv tool install` to drop
the anyOf block and require ["agent_name", "entry"] instead. The
handler still accepts `content` server-side as a kwarg alias, so
callers using either name keep working.

The workaround is idempotent and self-deactivating: once upstream
ships the fix the regex no longer matches and the RUN is a silent
no-op.

Also pin mempalace to 3.4.0 via a new MEMPALACE_VERSION build arg
so future bumps are a deliberate, reviewable diff rather than an
implicit pull of latest (an implicit upgrade is what swept the
broken schema in unannounced).

Refs MemPalace/mempalace#1728, MemPalace/mempalace#1735

CHANGELOG.md

@@ -13,7 +13,38 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 ## Unreleased
 
-_(no changes since v1.0.0)_
+_(no changes since v1.0.1)_
+
+## v1.0.1 — 2026-06-10
+
+Patch release. Works around an upstream MemPalace bug that broke pi at
+first prompt against the Anthropic Claude API.
+
+### Fixed
+
+- **`mempalace_diary_write` schema rejected by Anthropic API.** Mempalace
+  3.3.x and 3.4.0 advertise `diary_write`'s `input_schema` with a
+  top-level `anyOf: [{required:[entry]}, {required:[content]}]` to
+  express "either `entry` or `content` must be supplied". Anthropic's
+  tools API rejects top-level `anyOf` / `oneOf` / `allOf` outright, so
+  pi failed to register tools at session start with
+  `tools.<n>.custom.input_schema: input_schema does not support oneOf,
+  allOf, or anyOf at the top level`. `Dockerfile.base` now patches the
+  installed `mcp_server.py` after `uv tool install` to drop the `anyOf`
+  block and require `["agent_name", "entry"]` instead. The mempalace
+  handler still accepts `content` server-side as a kwarg alias, so
+  callers using either name keep working. Tracked upstream:
+  [issue #1728](https://github.com/MemPalace/mempalace/issues/1728),
+  [PR #1735](https://github.com/MemPalace/mempalace/pull/1735).
+  The workaround is idempotent + self-deactivating and will be removed
+  once a fixed mempalace release lands on PyPI.
+
+### Changed
+
+- **Mempalace pinned to 3.4.0** via `MEMPALACE_VERSION` build arg.
+  Future bumps must be a reviewable diff rather than an implicit pull
+  of `latest` (the broken 3.3.x/3.4.0 schema slipping in unannounced
+  is what caused this release).
 
 ## v1.0.0 — 2026-06-09