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).

extensions/pi/README.md

@@ -162,6 +162,30 @@ chosen at load time:
   dead archive, not in the shared palace. Use the agent's own palace tools
   (which go over HTTP), and mine backfills **on the palace host**.
 
+  **Setting these for a *native* pi install — there is no `.env` to edit.**
+  Worth stating plainly, because the obvious guess is wrong: **pi loads no
+  dotenv file and has no `env` block in `settings.json`**, and this extension
+  reads `process.env` and nothing else (`createClient()` →
+  `process.env.MEMPALACE_REMOTE_URL`). A native install therefore inherits
+  whatever **the shell that launches `pi`** exports — that is the only hook.
+  So export them from your shell rc, or from a file it explicitly sources:
+
+  ```sh
+  # ~/.zshrc (or ~/.bashrc) — if you keep secrets in ~/.config/pi/.env,
+  # nothing sources it for you; do it yourself:
+  set -a; [ -f ~/.config/pi/.env ] && . ~/.config/pi/.env; set +a
+  ```
+
+  Two traps. A pi launched from a **GUI** (Spotlight, dock, an editor's
+  terminal that spawns a non-login shell) does not necessarily read that rc, so
+  it can silently stay on the local palace. And exporting the variable in the
+  shell where you *edited* the rc does not affect an already-running pi — the
+  transport is chosen once at extension load. Confirm the result the same way
+  as a container flip: ask the agent for `mempalace_status` and check the
+  reported palace path is the **remote** host's, not your own
+  `$HOME/.mempalace/palace` — see
+  [`docs/phase-1-exposure-runbook.md`](../../docs/phase-1-exposure-runbook.md) §3.8.
+
   Serve such an endpoint with `mempalace serve --host 172.17.0.1 --port 8765`
   (the `pi-devbox` / `opencode-devbox` repos ship a
   `docker-compose.mempalace.yml` for exactly this).