docs(changelog): release v1.8.14

Converts the Unreleased section and records what this build carries beyond it:
the mempalace-toolkit bump that makes closing replies reach the mailbox
(deriveClosed, 21023e7 -> e45f6b4), and the L0-L4 subtask documentation landing
via pi-toolkit adfb553 + pi-extensions c64c122.

Notes the mechanism that makes the toolkit fix land at all — the resolved
toolkit SHA is folded into the content-addressed base tag, so the toolkit
moving forces a base rebuild rather than waiting for one — and the consequence
for the amd64 item already in this section: v1.8.13's base was cached, so
Dockerfile.base:607's agent-browser assertion never ran. This base is not
cached, so the native-amd64 proof is finally collected instead of discarded.

CHANGELOG.md

@@ -11,7 +11,7 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 ---
 
-## Unreleased
+## v1.8.14 — 2026-09-08
 
 **A test that was quietly checking nothing, and a version number that was wrong.**
 Both found by delegating a read-only audit of this repo to a headless worker
@@ -79,6 +79,60 @@ therefore asking for the impossible, while CI already had the answer and was
 discarding it. `Dockerfile.base:607` does assert it (`agent-browser --version &&`),
 but only when the base actually rebuilds — and v1.8.13's base was cached.
 
+**The mailbox now announces replies that CLOSE your own asks.** `mempalace-toolkit`
+`21023e7` → `e45f6b4`, which adds `deriveClosed()` alongside `deriveOwed()`. The old
+path queried `status: open` and joined for a reply, which by construction can only
+surface asks *you owe someone else*; a terminal reply carries `status: applied`
+(or `blocked`/`failed`), so **the answer to your own question was structurally
+invisible** — the one notification a human actually wants. Measured: `emb-7kj4vr4g`
+closed the v1.8.13 rollout ask at 18:31Z with `status=applied`, the operator
+reasonably expected to hear about it, and the mailbox stayed silent while being
+correct by its own definition. Nine closed correlations were sitting unannounced.
+Shares the 1-hour resurface floor, so a close is announced once and is news rather
+than a nag.
+
+This lands **because the base rebuilds**, which is worth stating explicitly: the
+CI-resolved `mempalace-toolkit` SHA is folded into the content-addressed base tag
+(`base-decide`), precisely so a toolkit-only fix cannot silently fail to land
+behind an unchanged `Dockerfile.base`. The floating `main` ref was left alone on
+purpose — the toolkit moving *forces* the rebuild rather than waiting for one.
+
+**A consequence worth noting for the amd64 item above: this release actually
+collects that proof.** v1.8.13's base was cached, which is why
+`Dockerfile.base:607`'s `agent-browser --version &&` never ran. v1.8.14's base is
+not cached, so both that assertion and the new `EXPECTED_NODE_MAJOR` gate execute
+on a native `linux/amd64` runner. The fleet's first *kept* amd64 runtime proof for
+the `linux-x64` ELF should be an artefact of this build rather than something
+asked of a device that cannot supply it.
+
+**Subtask delegation is documented — including the rung nobody built.** The image
+picks these up through their resolved refs (`pi-toolkit` `adfb553`,
+`pi-extensions` `c64c122`, the latter also refreshing the baked fallback skill):
+
+- an operator-facing decision guide in pi-toolkit's `README.md`, built on the
+  L0–L4 context ladder — how much of the parent session a child can see is the
+  axis that explains nearly every observed good and bad behaviour;
+- the canonical `pi-extensions` skill gains the same ladder next to *Boundary
+  discipline*, which until now diagnosed why an inherited transcript defeats a
+  brief without offering any alternative to "don't fork that";
+- one bullet in the global `AGENTS.md`, so the choice is visible without loading
+  a skill, and naming `pi-task` as a **CLI** — an agent hunting for a `pi_task`
+  tool finds none and concludes it is unavailable.
+
+What the ladder records: **L0/L1/L2 exist** in `pi-task` (`context.facts` /
+`.files` / `.commands`), **L4** is `fork`'s only behaviour (`getHeader()` +
+`getBranch()`, no offset or limit anywhere in the call chain), and **L3** — a
+truncated branch — **is not implemented by anything**, which is now written down
+instead of being a design idea somebody remembers.
+
+Also recorded, found while writing the above: `pi-fork/src/runner.ts:188` reads
+`if (extensions !== null) args.push("--no-extensions")`. So `extensions: []` turns
+the capability floor **on** and `null` turns it **off** — and `null` is the
+documented way to "restore normal extension loading", so tidying `[]` to `null`
+as a no-op re-arms palace writes inside every fork child. `pi-task` hardcodes the
+flag and cannot drift this way. Documented in three places because the edit that
+triggers it looks harmless.
+
 ---
 
 ## v1.8.13 — 2026-09-06