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.

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