docs(§7.2): measure the shared-palace sync blast radius — it is 0 today, and the feeder is what changes that

Unscoped `mempalace_sync` dry-run against the live primary (14,829 drawers):
out_of_scope 14391, no_source 438, missing 0, kept 0. Zero drawers deletable.

The mechanism is the finding: an entirely-absent source root yields
`out_of_scope`, NOT `missing`, and only missing/gitignored drawers get removed.
So a wipe needs the root to EXIST while files under it do not -- not merely a
host that lacks the repos. §7.2's "from a laptop that lacks the repos, it is a
fleet-wide wipe" therefore overstates today's risk.

It also understates tomorrow's, which is the part worth acting on. Two guards
currently prevent the laptop scenario and neither was designed to: the CLI has
no remote support, so a client's `mempalace sync` cannot reach central at all;
and the MCP tool runs server-side on synlig, where clients' /workspace roots do
not exist. That is safety by coincidence of layout.

The feeder's remote mode dissolves it: it rsyncs staged transcripts into
per-device inboxes ON synlig, so those sources begin existing on the palace host
and become in-scope for the first time. A later stage rotation or inbox cleanup
then marks that device's conversation drawers `missing` -- prunable, and
prunable from a different device. mempalace-pi-session already documents the
single-machine form of this; a shared palace makes it cross-device.

So stage retention on synlig plus the sync guard belong to enabling the feeder
fleet-wide, not to a later cleanup pass.

docs/rfc-001-global-palace.md

@@ -572,6 +572,27 @@ data-dependent rather than obvious. From a laptop that lacks the repos, it is a
 **Action:** edge blocks `mempalace_sync` from ever reaching the primary; document it; consider an
 upstream `--refuse-shared` guard.
 
+> **Measured on the live primary, 2026-08-15 — the threat model is not where this section puts it.**
+> An unscoped `mempalace_sync` dry-run against central (14,829 drawers) reports
+> `out_of_scope: 14391`, `no_source: 438`, **`missing: 0`, `kept: 0` — so zero drawers are currently
+> deletable.** The mechanism matters: a source root that is *entirely* absent yields **`out_of_scope`,
+> not `missing`**, and only `missing`/`gitignored` drawers are removed. A wipe therefore needs the root to
+> **exist** while the files under it do not — not a host that simply lacks the repos.
+>
+> Two corrections follow. **(a) The "laptop" scenario is currently blocked twice over**, and neither
+> guard was designed for this: the CLI has no remote support at all, so `mempalace sync` on a client
+> physically cannot reach central; and the MCP `mempalace_sync` tool executes **server-side on synlig**,
+> where clients' `/workspace/...` roots do not exist — hence `out_of_scope`. Do not mistake this for
+> safety by design; it is safety by coincidence of layout, and it decays.
+> **(b) The real hazard arrives with the transcript feeder's remote mode.** That mode rsyncs staged
+> transcripts into per-device inboxes **on synlig**, so those source files *will* exist on the palace
+> host — making them in-scope for the first time. Any later stage rotation, cleanup, or per-device inbox
+> removal then reclassifies that device's conversation drawers as `missing`, i.e. **prunable, and
+> prunable by a sync triggered from a different device.** `bin/mempalace-pi-session` already documents the
+> local form of this ("do NOT run `mempalace sync` while the stage is missing, or the drawers mined from
+> it get pruned"); shared-palace multi-device turns it cross-device. **Settle stage retention on synlig,
+> and the sync guard, as part of enabling the feeder fleet-wide — not after.**
+
 ### 7.3 Provenance belongs to the sync boundary — not to the agent, and not to a solitary container
 
 Today every drawer carries exactly `{wing, room, source_file, added_by, filed_at, id_recipe}`