docs(changelog): note the mempalace feed-tick fix this image carries

The recurring "[mempalace ext] feed (tick) failed: mine timed out after 30000ms"
message is fixed in mempalace-toolkit (309980b + e68ee20) and this image is what
delivers it, since CI resolves MEMPALACE_TOOLKIT_REF to a commit SHA at build
time. Worth a changelog entry rather than leaving it implicit in a ref bump: it
is the most visible symptom operators on this fleet have been living with, and
the entry records that it was a genuine defect (overlapping mines on a
single-writer palace) rather than the cosmetic annoyance it was parked as.

CHANGELOG.md

@@ -225,6 +225,28 @@ the one fact that is decided at **build** time and cannot be recovered later.
 Older images degrade cleanly — the field is absent, `jq // empty` yields nothing,
 and the line prints plain `baked` exactly as before.
 
+**This image also carries a real fix for the recurring
+`[mempalace ext] feed (tick) failed: mine timed out after 30000ms` message** that
+has been appearing in the pi TUI across the fleet since August
+(`mempalace-toolkit` `309980b` + `e68ee20`, picked up because CI resolves
+`MEMPALACE_TOOLKIT_REF` to a commit SHA at build time). It was parked as cosmetic
+on 2026-08-27 and it was not cosmetic: `lastFeedAt` was recorded only after a
+*successful* wait, but the extension's `Promise.race` abandons only the **wait**
+and cannot cancel the mine, so a timeout left the 10-minute debounce clock stale
+— and with `feedInFlight` already cleared, **both** guards stood open and every
+following settled turn started another mine on top of the one still running.
+Overlapping writers on a single-writer palace, each making the next slower and
+the next timeout likelier, which is why the message appeared many times per
+session instead of at most once per debounce window. Simulated over ten minutes
+of settled turns with a 60s mine: **16 mines launched, 15 of them overlapping**
+before; **2 and 0** after. Nothing was ever lost — the transcript is staged
+before the mine and `mine --mode convos` is idempotent — so this was wasted work
+and a misleading error, not data loss. The deadline also rose from 30s to 5
+minutes: the mine is the slowest call the extension makes (30–60s normally) yet
+carried the tightest deadline, 4x tighter than the `prepare` before it and 10x
+tighter than the init handshake. On a healthy fleet the message should now be
+absent; if it appears it is informative — a mine exceeding five minutes.
+
 ---
 
 ## v1.8.14 — 2026-09-08