skills: refresh vendored mempalace snapshot a12fe5e -> e9e09d9, re-pin the canary

Folded into v1.8.13 at zero marginal cost: the snapshot is hashed into
base_tag, but Dockerfile.base already changed this release, so the ~67 min base
rebuild was already being paid. vendor-mempalace-skill.sh --check reported exit
0 (stale-but-truthful) beforehand, so skipping was sanctioned -- this is the
deliberate call the release checklist asks for. Upstream content: the bare
project-name wing convention and the <harness>@<device> added_by rule, both
downstream of the attribution defect measured on this device 2026-09-06.

The canary re-pin matters more than the refresh. Its old pair ("Provenance is
stamped for you" present / "Attribute what you file yourself" absent) still
PASSED against the new snapshot, so leaving it would have yielded a canary
green on both old and new bytes -- blind to exactly the refresh it exists to
witness, the same false-green family as the pre-v1.8.5 canary. New pair chosen
by measuring direction against both files rather than reading the diff
("Diaries self-heal; plain drawers do not" new=1/old=0; "Agent diaries live in"
new=0/old=1), then tested two-sided: PASS on refreshed bytes, FAIL on the old
bytes recovered from git.

Gates after the change: smoke-test.sh parses, vendor --check exit 0,
check-base-hash exit 0.

CHANGELOG.md

@@ -121,6 +121,27 @@ Smoke asserts the floor is `[]` specifically, not merely falsy — `null` is the
 unguarded state, so a "truthy or not" test would pass on exactly the
 configuration being guarded against.
 
+**Vendored mempalace skill snapshot refreshed `a12fe5e` -> `e9e09d9`, and the
+phrase canary re-pinned with it.** Folded in at zero marginal cost: the
+snapshot is hashed into `base_tag`, but `Dockerfile.base` already changed this
+release, so the ~67 min base rebuild was already being paid. `--check` reported
+exit 0 (stale-but-truthful) beforehand, i.e. skipping was sanctioned — this is
+the deliberate decision the checklist asks for, not a drive-by. Upstream content
+is the fleet wing-naming convention (bare project names, no `wing_` prefix) and
+the `<harness>@<device>` rule for `added_by`, both of which came out of the
+attribution defect measured on this device on 2026-09-06.
+
+The canary re-pin is the interesting half. Its old pair — "Provenance is
+stamped for you" present, "Attribute what you file yourself" absent — STILL
+PASSED against the new snapshot, so leaving it in place would have produced a
+canary that is green on both the old and the new bytes: blind to precisely the
+refresh it exists to witness, which is the same false-green family the
+pre-v1.8.5 canary died of. The replacement pair was picked by MEASURING
+direction against both files rather than by reading the diff ("Diaries
+self-heal; plain drawers do not" new=1/old=0; "Agent diaries live in"
+new=0/old=1) and then tested two-sided: PASS on the refreshed bytes, FAIL on the
+old bytes recovered from git. A canary that cannot fail is decoration.
+
 **`credential-incident-response` §5/§6 corrected — a stated mechanism was wrong,
 and this is the second time in three days this section named a wrong reason
 for a zero.** Docs only.