docs: native pi has no .env to flip, and EMB-7KJ4VR4G has no native pi

Follow-up to ec436ed, closing the one item that commit left as "unverified".

Verified on the EMB-7KJ4VR4G host: native pi is not installed at all -- no `pi`
or `mempalace` on PATH, no ~/.config/pi/, no ~/.pi/agent/extensions/. That
host's ~/.mempalace exists solely to back the devbox container through the bind
mount (.devbox-owner holds 1000:1000). So the 2026-08-14 flip covers every pi
on that machine and there is no split-brain to fix. The general hazard stays
documented, because it is a per-machine question.

Also documents how a native install *would* be flipped, since the obvious guess
is wrong: pi loads no dotenv file and has no `env` block in settings.json, and
the extension reads process.env only. The launching shell is the sole hook, so
the vars must be exported from a shell rc (a GUI-launched pi may not read one),
and ~/.config/pi/.env is not sourced by anything automatically.

docs/phase-1-exposure-runbook.md

@@ -442,9 +442,15 @@ moment of the flip, so anything the agent filed into central since then will not
   publishes only on `v*` tags and the latest tag *is* the currently deployed image — built on
   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 nobody has
-  checked. If the container is flipped and native pi is not, that machine writes into two different
-  palaces and its memory silently splits in two. Verify per machine with the §3.8(c) path check.
+- **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.
+  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.
 - **§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).