docs: reconcile the RFC-001 docs with what is actually deployed

Audit of every doc touching the global-palace rollout against the running
fleet. Each correction below was verified against the filesystem or the host,
not against another doc:

- synlig-primary-runbook: the decommission `rm -rf ~/.mempalace` now carries a
  STOP block. That tree holds the fleet palace *and* the only copy of the
  bearer token every client authenticates with; the old "empty today" comment
  stopped being true when the palace was seeded on 2026-08-14. Adds an ordered
  safe decommission, and drops count-based join verification.

- phase-1-exposure-runbook: new S3.8, how to verify a flip actually took --
  the procedure that until now existed only in an untracked handover file.
  Three claims that fail independently (env var / curl / the palace-path
  discriminator) plus an explicit list of checks that produce FALSE POSITIVES:
  drawer counts (both sides were seeded from the same palace, and `status`
  counts chunks not drawers), write-then-read through the same transport, and
  the `mempalace` CLI -- which has no remote support at all, so post-flip it
  reads the dead local archive and reports success.

- rfc-001: status Draft -> Phases 0-1 implemented. Records that the join was a
  file-level copy, which SIDESTEPPED the S7.6 diary-dedup question rather than
  answering it -- so S7.6 remains a hard blocker for the second machine, which
  is the one that will actually exercise merge semantics.

- ARCHITECTURE, SKILL, contrib/README, extensions/pi/README all claimed pi
  feeds the palace automatically, unconditionally. That is gated on
  mempalace-toolkit >= 29e660e and every deployed image predates it, so the
  claim is currently false fleet-wide. Each site now states the gate plus a
  check that inspects the *deployed* file rather than repo HEAD.

- extensions/pi/README: plaintext http://mempalace.lan example -> https
  endpoint; the two transports are either/or (no dual-write, no local mirror);
  the bridge fails CLOSED, so "the agent has no mempalace_* tools" is the
  expected symptom of a server/token/DNS fault, not of a broken install.

- contrib/README: documents mempalace-serve.service, which this directory has
  shipped since day one without explaining it (linger, the load-bearing
  172.17.0.1 bind and why loopback is the unsafe-looking-safe option, the
  token path, and an uninstall warning).

- Fixes a pre-existing stray ```sh fence that was swallowing S3.2's heading and
  the token command into a code block.

Docs only; no behaviour change.

SKILL.md

@@ -20,11 +20,17 @@ The `mempalace` skill covers *using* the palace (search, diary, KG). This skill
 
 Both follow the same **stage-to-cache-then-mine** idiom — they curate input into `~/.cache/…/<wing>/`, then delegate to `mempalace mine`.
 
-**Pi is out of scope for this skill.** The pi coding-agent has its own
-wrapper, `mempalace-pi-session`, but — unlike opencode — pi's bridge
+**Pi is out of scope for this skill — conditionally.** The pi coding-agent has
+its own wrapper, `mempalace-pi-session`, but — unlike opencode — pi's bridge
 extension (`extensions/pi/mempalace.ts`) invokes it automatically on session
-shutdown and a debounced mid-session tick, so a pi machine with that
-extension installed needs none of this skill's manual/scheduled recipe. See
+shutdown and a debounced mid-session tick, so a pi machine running
+**mempalace-toolkit ≥ `29e660e` (2026-08-12)** needs none of this skill's
+manual/scheduled recipe. Older installs — and any container image baked before
+that date — **do** still need it: having the extension is necessary but not
+sufficient, because the pre-`29e660e` extension has no feed path at all.
+Check the *deployed* file rather than the repo:
+`grep -c MEMPALACE_FEED "$(readlink -f ~/.pi/agent/extensions/mempalace.ts)"`
+— zero means fall back to the recipes below. See
 `extensions/pi/README.md` § Automatic transcript feeding in the same repo.
 
 ## When to Load This Skill