changelog: adopt pi-studio v0.9.61 and mempalace-toolkit 975ab92

Both are floating refs that moved since v1.9.4, so the next tag would bake them
either way; the gate's complaint was that nothing in the repo said so. Naming
them is the fix the gate actually asks for.

mempalace-toolkit 2167a1b -> 975ab92 adds mailbox dormancy: an ask may declare a
`dormant_unless` predicate and is withheld from the ANNOUNCED owed-set while
every condition still matches its baseline. It is backward compatible by
construction -- an ask without the key behaves exactly as before -- and
fail-visible: any predicate that cannot be evaluated announces the ask rather
than hiding it, because the dangerous failure is work that disappears, not a
spurious nag.

pi-studio v0.9.60 -> v0.9.61 is adopted as-is. NOT pinned, deliberately, and the
reason is worth recording: check-doc-drift.sh gives pi-studio kind `studio`,
which resolves the highest semver TAG of the upstream repo and ignores
PI_STUDIO_REF entirely (resolve_studio, ~line 551). Setting
PI_STUDIO_REF=v0.9.61 would therefore not be tracked by the gate -- the moment
upstream tags v0.9.62 the gate would report DRIFT against a value we no longer
bake, i.e. a false positive by construction. Pinning pi-studio is a coherent
thing to want, but it requires moving it from kind `studio` to kind `ref` in the
gate at the same time, which changes release-gate semantics and is a separate
decision from adopting this release.

Still drifting, and left drifting on purpose: pi-obsmem e7d77dc -> 731c3d4.
PI_OBSMEM_REF=master is CI-resolved at build time, master is 4 commits ahead of
the 3.1.4 tag, and the newest tag remains 3.1.4 -- so PR #83 ("Fix Pi 0.87
memory worker compatibility", merged 2026-09-23) is still reachable only from
master. Whether to bake an unreleased master or stay on 3.1.4 and hold pi is a
pin decision with a silent failure mode behind it (obsmem's peerDeps are all
`*`), so it is not being made in a changelog commit.

CHANGELOG.md

@@ -25,9 +25,28 @@ base packages. Nothing here changes a pin. `entrypoint-user.sh` and
 | Component | Baked in v1.9.4 | Next build | Why |
 |---|---|---|---|
 | pi-extensions | `25c1265` | **`143a214`** | `install.sh`: skip hook activation on a clone this user cannot configure (below) |
+| mempalace-toolkit | `2167a1b` | **`975ab92`** | mailbox: an ask can declare `dormant_unless`, so deliberately-waiting work stops being announced (below) |
+| pi-studio | `v0.9.60` (`e04fc7a`) | **`v0.9.61`** (`641aa32`) | upstream release, adopted as-is; `-studio` variant only |
 
 ### Added
 
+- **Mailbox: an ask can declare its own dormancy (`mempalace-toolkit` `975ab92`)**
+  — a first-boot acceptance ask is planted deliberately unanswerable, describing
+  work that becomes possible only when the device is next recreated, and it must
+  stay owed until then because closing it early to tidy the mailbox is how that
+  work gets lost. `deriveOwed` could not tell that apart from neglected work, so
+  such an ask was announced at every session start and every poll for as long as
+  it was correctly waiting — three days running on `emb-7kj4vr4g`
+  (2026-09-28 → 2026-10-01) and across three consecutive releases before that.
+  An ask may now carry a `dormant_unless` predicate (`file_mtime` / `json_field`
+  against local paths) and is withheld from the *announced* owed-set while every
+  condition still matches its baseline, returning the moment any differs.
+  Withheld from the announcement, never from the mailbox: the wake-up injection
+  still lists dormant asks once per session. Unevaluable predicates announce the
+  ask — dormancy is proven, never assumed — and an ask without the key behaves
+  exactly as before. Nothing in the image changes except the bridge the
+  `MEMPALACE_TOOLKIT_REF=main` clone already tracks.
+
 - **Four base packages: `sqlite3`, `bc`, `dc`, `bsdextrautils`** — requested
   2026-09-28 after a session had to reach for `bc` and found it absent. 1311 KB
   total, and ZERO transitive packages: `libsqlite3-0`, `libreadline8t64`,