v1.8.6: adopt pi 0.84.3 + mempalace 3.8.0, close the v1.8.5 doc/observability gaps

Three coupled pieces of work, all of which ride on the base rebuild that the
mempalace bump forces anyway.

DRIFT ADOPTED
- pi 0.84.2 -> 0.84.3. Its release notes carry a "Breaking Changes" line
  (GoogleThinkingLevel -> GoogleApiThinkingLevel). Audited before adopting:
  zero references across all four vendored companions (pi-fork,
  pi-observational-memory, pi-atelier, pi-studio), so it is inert for us. The
  reason to adopt is two skill-discovery fixes that land directly on v1.8.5's
  vendored-skill work: nested Markdown skills inside grouping directories were
  not discovered, and root README.md/AGENTS.md in skill dirs were reported as
  broken skills.
- mempalace core 3.7.1 -> 3.8.0. Additive/reliability only. Its sync fix
  (#2320/#2322) stops sync --apply deleting drawers whose source_file was
  unreachable *at that moment* -- which does NOT relax the standing landmine
  against sync on the shared palace, because that landmine is about paths
  permanently absent from whichever host runs the sync. Different failure
  shape; the caution stands.

DOCS -- three defects, one of them public
- DOCKER_HUB.md advertised "neovim (LazyVim defaults)". Nothing in the image
  installs LazyVim; the only nvim config is a 19-line sysinit.vim. CI PATCHes
  this file into the Docker Hub description on every release, so this was a
  false claim published to the world. Removed.
- agent-browser + Playwright + Chromium is the single largest addition in the
  image (~625 MB) and had zero mentions in README, DOCKER_HUB or THIRD_PARTY --
  it was documented only to agents, in the AGENTS.md managed block. Now
  documented to humans, including the Chromium licence dimension.
- typst and socat appeared in README prose but not in the "What's inside"
  inventory. Added.

OBSERVABILITY -- the three gaps v1.8.5 listed as still open
- build-manifest.json now records mempalace core, read from the live binary
  (ground truth, not the build ARG). Placed as a sibling of pi_version rather
  than inside components{}, because pi-devbox-version renders that map through
  [0:12] and would truncate a version string.
- smoke asserts the pi-observational-memory clone actually CONTAINS the ce9fc98
  auth fix, pinned to src/runtime.ts. Deliberately not a repo-wide grep: two of
  the three markers also live under tests/, so the repo-wide form stays green
  with the fix site reverted. That is the third false-green of this exact family
  in this repo (canary phrase in both snapshots; reconciler fixture using a
  non-owned name; now this) -- pin containment checks to the fix site.
- smoke asserts the feeder's pi@<device> agent default behaviourally. The
  earlier audit concluded this needed a --print-config added upstream; it does
  not. AGENT is assigned before arg parsing, so `bash -x mempalace-pi-session
  --help` observes the real resolution with no toolkit change. Two-sided:
  device set => pi@<device>, unset => must not be pi@*.
- pi-devbox-version now prints a palace: line with the same live-vs-baked drift
  detection pi already had. This matters more than it looks: mempalace is the
  one component that is both client (here) and server (synlig), so skew between
  them is a real failure mode. Degrades quietly on pre-v1.8.6 images.

Deferred deliberately: a native arm64 act_runner on tor-ms22 (the current
runner is on synlig, x86_64, so every arm64 layer ships QEMU-emulated).
Analysis and caveats filed to the palace rather than actioned here.

CHANGELOG.md

@@ -11,7 +11,175 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 ---
 
-## Unreleased
+## v1.8.6 — 2026-08-25
+
+Patch release. Adopts the drift that accumulated in the ~2 days since v1.8.5
+(pi `0.84.3`, mempalace core `3.8.0`), then closes the documentation and
+observability gaps that v1.8.5 itself listed as "Still open". No component
+was adopted without an audit note recording *why* it is safe.
+
+All moving refs re-resolved immediately before tagging (2026-08-25T13:28Z):
+pi-toolkit `0e1369e6`, pi-extensions `20228878`, mempalace-toolkit `0fe64c48`
+and pi-observational-memory `ce9fc982` all unchanged since v1.8.5;
+pi-fork `f1ff8087` → `bf702b4c`; pi-atelier holds at `v0.8.2` (floor for
+pi ≥0.84 satisfied); pi-studio's CI-resolved newest tag has moved again to
+`v0.9.51`. Base rebuild is forced (Dockerfile.base changed), so the 16
+floating base-tooling ARGs re-roll — expect ~67 min as for v1.8.5.
+
+### Changed
+
+- **`mempalace` core `3.7.1` → `3.8.0`.** Released 2026-08-23T21:19Z, hours
+  after this project's own v1.8.5 tag the same day. Additive/reliability only
+  — reviewed for MCP tool-schema changes before bumping, as always: none.
+  `sync --apply` (PR #2320/#2322) no longer deletes a drawer solely because
+  its `source_file` was unreachable *at that moment* — it asks for
+  corroboration first. **This does not relax the standing landmine** against
+  running `mempalace_sync` / `mempalace_delete_by_source` beyond dry-run on
+  the shared central palace: that failure mode is paths *permanently* absent
+  from whichever host runs the sync, not transient unavailability, and 3.8.0
+  doesn't touch it. Server-side perf fix PR #2307 (long-running Chroma servers
+  no longer invalidate their own HNSW cache on their own writes) likewise does
+  not make `mempalace_reconnect` unnecessary — that tool covers *external*
+  writes bypassing the in-process client, a different scenario. Full reasoning
+  lives in the `Dockerfile.base` comment above `ARG MEMPALACE_VERSION`.
+  **Deployment note:** synlig's central palace currently serves `3.7.1`
+  server-side via `docker-compose.mempalace.yml` (which reuses this image) —
+  this client bump introduces version skew until that stack is separately
+  redeployed; sequence accordingly.
+
+- **`pi` `0.84.2` → `0.84.3`.** Published 2026-08-24T11:09Z. Release notes
+  carry one "Breaking Changes" line — `GoogleThinkingLevel` renamed to
+  `GoogleApiThinkingLevel` — checked against all four vendored packages
+  (`pi-fork`, `pi-observational-memory`, `pi-atelier`, `pi-studio`): zero
+  references, inert here. 0.84.3 also fixes two skill-discovery bugs that
+  land directly on this repo's own vendored-skill work: nested Markdown
+  skills inside `.agents/skills/` grouping directories not being discovered,
+  and root Markdown files (`README.md`/`AGENTS.md`) in skill directories being
+  wrongly reported as broken skills.
+
+### Added
+
+- **Browser automation is now documented to humans, not just to agents.**
+  `agent-browser` + Playwright + a headless Chromium (~625 MB — the single
+  largest addition in the image) previously had zero mentions in `README.md`,
+  `DOCKER_HUB.md` or `THIRD_PARTY.md`; it existed only in the agent-facing
+  `AGENTS.md` managed block. Added a `README.md` "Browser automation"
+  subsection, a `DOCKER_HUB.md` feature entry, and `THIRD_PARTY.md` license
+  rows for `agent-browser` (Apache-2.0), Playwright (Apache-2.0), and Chromium
+  (BSD-3-Clause for Chromium's own code plus a large set of bundled
+  third-party components under their own licenses; the binary here is not
+  compiled by this repo — it's Playwright's own "Chrome for Testing" download
+  via `playwright install --with-deps chromium`).
+- **`THIRD_PARTY.md` gains rows for `pi-atelier` (MIT) and `mempalace` core
+  (MIT per the GitHub repo; noted that the PyPI package's own metadata omits
+  a license classifier, so verify against the repo's `LICENSE` rather than
+  sdist/wheel metadata if clearance is needed from the artifact alone).**
+- **`typst` and `socat` added to `README.md`'s tooling inventory.** Both were
+  already used in prose (typst as pandoc's `--pdf-engine`, socat by
+  `studio-expose`) but missing from the "What's inside" lists, so the
+  inventory didn't match what the image actually ships.
+- **`mempalace` core version recorded in `/etc/pi-devbox/build-manifest.json`.**
+  Previously absent — a published image couldn't answer "which palace version
+  shipped?", and a palace bug couldn't be correlated to an image version.
+  Derived from the live installed binary (matching the manifest's existing
+  ground-truth-not-build-args philosophy), degrading to `null` rather than
+  failing the build if the binary is missing or its output format changes.
+  Verified landed: new top-level `"mempalace_version"` key, sibling to
+  `pi_version` rather than a member of `components{}` (that map is rendered
+  truncated to 12 chars by `pi-devbox-version`, which would mangle a longer
+  version string).
+- **New smoke assertions**, all landed in `scripts/smoke-test.sh`: (1) the
+  `pi-observational-memory` clone is checked for the actual `ce9fc98`
+  auth-fix markers pinned to their fix site, `src/runtime.ts`
+  (`availability_recheck`, `providerCredentialConfigured`,
+  `hasConfiguredAuth`) — not merely clone existence, and deliberately not a
+  repo-wide grep: all three identifiers also appear under `tests/`, so a
+  repo-wide search would stay green even with the fix reverted in
+  `src/runtime.ts` alone; (2) the manifest's new `mempalace_version` field is
+  asserted present, non-null, and equal to what `mempalace --version` reports
+  live, so the manifest can't silently drift from the installed package —
+  expected to fail against any pre-v1.8.6 image, by design; (3) a
+  behavioural check for the mempalace-toolkit feeder's `--agent` default
+  (see below — this one turned out to be possible after all).
+
+### Fixed
+
+- **A false claim was being published to Docker Hub on every release.**
+  `DOCKER_HUB.md` advertised "neovim (LazyVim defaults)". Nothing in this
+  repo installs LazyVim — the only nvim configuration is a 19-line
+  `sysinit.vim` that sets `termguicolors`. `update-description` pushes this
+  file verbatim (with `{{PI_VERSION}}` substituted) to the Hub description, so
+  the error was public, not internal. Corrected to describe what's actually
+  there.
+
+### Component audit for this release
+
+Checked against upstream 2026-08-25 (two days after v1.8.5's own audit):
+`mempalace` core moved `3.7.1` → `3.8.0` (see Changed, above — timing is
+notable: released *hours after* v1.8.5 tagged, so v1.8.5 could not have caught
+it no matter how carefully it was audited). `pi` moved `0.84.2` → `0.84.3`
+(see Changed). `pi-toolkit` `0e1369e6`, `pi-extensions` `20228878`,
+`pi-observational-memory` `ce9fc982`, and `pi-atelier` `v0.8.2` are all
+**unchanged** from v1.8.5 — in particular `pi-observational-memory` still sits
+exactly at the auth-fix commit with nothing landed upstream since, and
+`pi-atelier` is still the newest tag with the `≥0.7.1` floor for `pi ≥ 0.84`
+trivially satisfied. `pi-fork` has one upstream commit not adopted this
+release: `f1ff8087` → `bf702b4c`, a text-only rewording of the fork task
+preamble (no code-path change) — **left un-pulled** for this release since it
+is a moving ref CI resolves fresh at every build anyway; it will be adopted
+automatically on the next build regardless of this entry. `pi-studio` (studio
+variant) has drifted two tags upstream, `v0.9.48` (pinned at build time via
+CI's newest-semver-tag resolution) → `v0.9.51` at tag time, purely additive
+(watched PDF previews, opening PDFs directly in Studio, Studio header
+hide) — nothing to bump in this repo since studio-tag resolution happens in
+CI, not the Dockerfile, but note it **will** auto-adopt `v0.9.51` on the next
+studio-variant build. `mempalace-toolkit` unchanged — this release's manifest
+and pi-bump work in `Dockerfile.variant` stayed within that file's ownership
+and did not require a toolkit-side change.
+
+### Still open
+
+- **`MEMPALACE_VERSION` has no CI-side audit equivalent to `PI_VERSION`'s.**
+  `PI_VERSION` is verified published-on-npm and warns (never silently adopts)
+  on drift; `MEMPALACE_VERSION` is a literal Dockerfile string with zero
+  references in `.gitea/workflows/docker-publish.yml`. Flagged in v1.8.5's
+  audit as a gap; still a gap.
+- **`pi-devbox-version`'s human-readable output does not display
+  `mempalace_version`.** Its render path is a fixed sequence
+  (`release_tag`, `build_date`, `source_revision`, `pi`, then `components{}`)
+  and the new top-level field isn't in it — only `--json` mode (which `cat`s
+  the manifest directly) surfaces it today. One line in
+  `rootfs/usr/local/bin/pi-devbox-version` would fix this; deferred since the
+  field's stated purpose (correlating a palace bug to an image) is already
+  served by `--json`, but worth doing in a follow-up if this becomes a
+  routine manual check.
+
+**Resolved during this release, not left open:** the feeder `--agent`
+default behavioural hook initially looked like it might need a
+mempalace-toolkit change (a `--print-config` flag that doesn't exist). It
+didn't — `mempalace-pi-session` assigns `AGENT` before argument parsing and
+`--help` exits 0 with no side effects, so `bash -x mempalace-pi-session
+--help` observes the real resolution (env interpolation and fallback)
+without needing a source change. The new smoke assertion exploits exactly
+that, checked both ways: with `MEMPALACE_PI_DEVICE` set it must resolve to
+`pi@<device>`; with it unset it must NOT be `pi@*` (catches a regression to
+the old unconditional `$USER`/`mempalace` default).
+  `mempalace-toolkit` commit `c64ffa1` changed the feeder's `--agent` default
+  from `$USER` to `pi@<device>`, but there is still no way for smoke to assert
+  this default is actually in effect from this repo alone, since
+  `mempalace-toolkit` is a separate repo this release does not modify. If the
+  concurrent smoke-test work could not find an honest assertion from the
+  existing `/opt/mempalace-toolkit` surface (help text, `--self-test`), this
+  remains open pending a toolkit-side `--print-config`-style hook — a
+  toolkit-repo change, not a pi-devbox one.
+- **16 base-tooling `ARG *_VERSION=latest` pins remain unrecorded.** (Corrected
+  count — v1.8.5's entry said "~14"; the actual count from `Dockerfile.base`
+  is 16, plus 5 more that float with no ARG at all: `rustup-init`, AWS CLI v2,
+  Chromium-via-Playwright, Node's minor version via `setup_22.x`, and
+  `DEBIAN_VERSION=trixie-slim` itself.) None of these are recorded anywhere
+  once the build completes — not in the manifest, not in a label — so a
+  published image cannot answer "which nvim/uv/chromium shipped?" without
+  exec-ing in and asking the binary.
 
 ### Documentation