docs: record the primary's real lineage — EMB-X1JY06WJ -> EMB-7KJ4VR4G -> synlig

Three docs said the primary was "seeded from EMB-7KJ4VR4G's palace", which is
true but stops one hop short. That palace was itself carried over from
EMB-X1JY06WJ, the previous work computer, when it was replaced around
2026-07-06.

Evidence, read read-only out of the frozen archive on EMB-7KJ4VR4G: 76 drawers
carry `source_machine=EMB-X1JY06WJ` and they are the oldest in the store --
earliest filed_at 2026-05-04, two months before that machine's stack existed --
with no other source_machine value present. The remaining ~16k were filed
locally afterwards (15,189 in July, 1,073 in August). Last write is
2026-08-14T15:07:06, the seed instant.

Two consequences, recorded in rfc-001 S4.4:

- It was the *second* whole-palace file copy, not the first, and both were
  single-source clones. So the method has two successes behind it and still
  zero exercises of merge semantics -- S7.6 is *less* tested than "we've done
  this twice" would suggest, not more.
- The primary now holds records from a machine that no longer exists, and
  `source_machine` is the only thing marking them. Not noise; don't prune it.

Also corrects a94eb7f, which inferred the archive's origin from the
`.devbox-owner` marker. That marker only records that the devbox adopted the
directory and says nothing about provenance -- the archive predates the stack.
And native pi on EMB-7KJ4VR4G is "not installed *yet*", a deferred hazard rather
than a closed one: a native install there would resolve its palace to
~/.mempalace, i.e. the frozen archive, and split that machine's memory from
central silently. Flip at install time.

docs/phase-1-exposure-runbook.md

@@ -7,8 +7,10 @@ items 2 and 5.
 
 > **Status 2026-08-14 — DONE. Exposed, seeded, and one client flipped.**
 > `https://mempalace.jordbo.se/mcp` has been serving since 2026-08-12 (§3.3–§3.6 are all ✅ below).
-> The palace was seeded 2026-08-14 15:07 from EMB-7KJ4VR4G (14,777 → 14,803 drawers), and that
-> machine's pi-devbox container is flipped and **verified end-to-end — see §3.8**, which is the
+> The palace was seeded 2026-08-14 15:07 from EMB-7KJ4VR4G (14,777 → 14,803 drawers) — whose palace was
+> itself carried over from the previous work computer **EMB-X1JY06WJ** around 2026-07-06, so the
+> primary's lineage is EMB-X1JY06WJ → EMB-7KJ4VR4G → synlig by two file-level copies (rfc-001 §4.4
+> Deviation) — and that machine's pi-devbox container is flipped and **verified end-to-end — see §3.8**, which is the
 > verification procedure that did not exist when the first flip was performed.
 > Still outstanding: the transcript feeder is **inert on every deployed image** (§3.7), and §7.6 is
 > still a hard blocker for the *second* machine to join (§4).
@@ -443,14 +445,19 @@ moment of the flip, so anything the agent filed into central since then will not
   pi-devbox ≥ `7c00dd6` **and** mempalace-toolkit ≥ `29e660e`. Both are required: the first restores
   the container-start catch-up, the second is where extension-side feeding was implemented at all.
 - **Whether *native* pi on a flipped machine was also flipped** is a per-machine question. Answered for
-  **EMB-7KJ4VR4G (2026-08-14): native pi is not installed there at all** — no `pi`/`mempalace` on the
-  host PATH, no `~/.config/pi/`, no `~/.pi/agent/extensions/`; that host's `~/.mempalace` exists only to
-  back the devbox container through a bind mount. So that machine needs nothing further. **Still open
-  for every other host**: a machine running native pi beside a flipped container writes into two
-  different palaces and splits its memory silently. Verify with the §3.8(c) path check, per machine.
+  **EMB-7KJ4VR4G (2026-08-14): native pi is not installed there *yet*** — no `pi`/`mempalace` on the host
+  PATH, no `~/.config/pi/`, no `~/.pi/agent/extensions/`; it is a replacement machine that has not had
+  native pi set up. So nothing further needs flipping there **today** — but this is a deferred hazard,
+  not a closed one: a native install resolves its palace to `~/.mempalace`, which on that host is the
+  bind-mounted **frozen archive**, so it would start writing there and split the machine's memory from
+  central silently. **Flip native pi at install time, not after.** **Still open for every other host**
+  running native pi beside a flipped container. Verify with the §3.8(c) path check, per machine.
   Note native pi has **no `.env` to edit** — pi loads no dotenv file and has no `env` block in
   `settings.json`, so the variables must come from the shell that launches it; recipe in
-  [`extensions/pi/README.md`](../extensions/pi/README.md#transport-local-vs-external) § Transport.
+  [`extensions/pi/README.md`](../extensions/pi/README.md#transport-local-vs-external) § Transport. On
+  EMB-7KJ4VR4G specifically, that tree's `config.json` also points at
+  `palace_path=/home/developer/.mempalace/palace` — a *container* path that does not exist on macOS — so
+  a native install must not inherit it unexamined.
 - **§7.2**: never run `mempalace sync` against the shared palace. Doubly true now that the pi/opencode
   feeders stage *inside* the palace root, which puts staged sources in scope for a sync of the palace dir.
 - **nyvaken's public FQDN and the web hotel's CNAME rules** — unverified (§3.4).