feeders: stage beside the palace, not in ~/.cache; document Phase 1 exposure

Staging default moves out of ~/.cache to <palace-root>/pi-stage (pi) and
<palace-root>/opencode-stage (opencode), resolved with mempalace's own
palace-path precedence ($MEMPALACE_PALACE_PATH -> $MEMPAL_PALACE_PATH ->
~/.mempalace/config.json -> ~/.mempalace/palace), then dirname.

Why: the convos miner keys dedup on the *staged* path, so a wiped stage plus a
sync scoped to include it prunes the drawers mined from those sources --
deleting memories, not a cache. Under ~/.cache that state was reachable by
anything treating a cache as disposable. Staging inside the palace makes the
coupling structural: the stage cannot be wiped without touching the palace
itself. Overrides ($MEMPALACE_PI_STAGE / $MEMPALACE_SESSION_STAGE, --stage) are
unchanged. Note the old default had never been created on any host, so this
closed a latent hazard, not a live one.

Measured, and the docs now claim only this much: sync prunes only within the
scope it is given -- wing-only, 1299 scanned / 1299 out of scope / 0 removed;
scoped at the palace root, 651 kept / 648 out of scope. The previous blanket
"sync prunes every drawer" wording overstated it, which is a liability: the next
reader disproves the overstatement and discards the real constraint with it.

Also in this change:
- cron log dir ~/.cache/mempalace-session -> ~/.cache/mempalace-logs. The stage
  left that namespace, so the old name now read as "the stage".
- AGENTS.md: the convos miner *does* check mtime (verified against upstream
  convo_miner.py); the previous "no mtime check" claim was wrong.
- smoke-test assertions use `mktemp -d` for --sessions-dir. One pointed at /tmp,
  which still held earlier synthetic transcripts, so a --dry-run exported a fake
  session into the real stage: --dry-run skips the mine, not the export.

docs/phase-1-exposure-runbook.md -- the newt/DNS/auth step that RFC 001 and the
synlig runbook leave open (runbook section 4, items 2 and 5). Port 8765 at /mcp,
newt targets 172.17.0.1, and the authentication is the single shared bearer
token (RFC 6.2, decided 2026-08-09) rather than per-device proxy users. The
latter cannot work today: mempalace validates exactly one token, and Pangolin's
SSO/PIN/password are browser-shaped while every client here is a headless
JSON-RPC POST -- enabling that protection breaks the clients it protects. The
per-device axis that *does* exist is the feeder's SSH key + per-device inbox.

New finding recorded there: a loopback bind does not merely 403 behind a tunnel
(already known, runbook 2.4) -- it also silently starts the server with no token
at all, because auto-minting is gated on the bind being non-loopback.

extensions/pi/README.md: the HTTP transport IS authenticated as of mempalace
3.6.0; the "sessionless and unauthenticated" note dated from the v1.3.0 era.
Closes the RFC section 8 Phase-0 hygiene item.

SKILL.md

@@ -20,6 +20,13 @@ The `mempalace` skill covers *using* the palace (search, diary, KG). This skill
 
 Both follow the same **stage-to-cache-then-mine** idiom — they curate input into `~/.cache/…/<wing>/`, then delegate to `mempalace mine`.
 
+**Pi is out of scope for this skill.** The pi coding-agent has its own
+wrapper, `mempalace-pi-session`, but — unlike opencode — pi's bridge
+extension (`extensions/pi/mempalace.ts`) invokes it automatically on session
+shutdown and a debounced mid-session tick, so a pi machine with that
+extension installed needs none of this skill's manual/scheduled recipe. See
+`extensions/pi/README.md` § Automatic transcript feeding in the same repo.
+
 ## When to Load This Skill
 
 - User asks "how does the palace get fed?" or mentions setting up mempalace on a new machine.
@@ -86,7 +93,14 @@ A docs-heavy repo should produce ~5–10 drawers per file. >15 drawers/file on a
 ### Dedup is free — re-running is safe
 
 - `mempalace-docs`: dedup keyed on `source_file` path + `mtime`. Unchanged files skipped.
-- `mempalace-session`: dedup keyed on `source_file` path alone (no mtime check for convos). Staging filenames are deterministic per session (`<slug>_<id>.jsonl`), so re-runs skip already-filed sessions.
+- `mempalace-session` / `mempalace-pi-session`: the convos miner also dedups
+  on `source_file` path + `mtime` (`file_already_mined(..., check_mtime=True)`
+  in upstream `convo_miner.py` — a prior version of this line said "no mtime
+  check", which was wrong). Staging filenames are deterministic per session,
+  so a re-run on unchanged content is a no-op, and a grown/changed session is
+  detected, purged, and refiled rather than duplicated. What must stay
+  stable is the staging *path itself* — wiping the staging dir makes dedup
+  (and `mempalace sync`) treat those sources as gone.
 
 Second run immediately after first → 0 new drawers, only the post-mine `repair` step runs (~5 min on 5k drawers).
 
@@ -110,8 +124,10 @@ mempalace-session --session ses_abc123        # one specific session
 ### Force re-mine
 
 ```bash
-rm -rf ~/.cache/mempalace-session/<wing>/     # nukes staging dir
+rm -rf <palace-root>/opencode-stage/<wing>/   # nukes staging dir
 mempalace-session                              # stages + mines fresh
+# Do NOT run `mempalace sync` between those two commands: with the stage gone,
+# a scoped sync prunes the drawers mined from it instead of refiling them.
 ```
 
 Staging is ephemeral by design; the palace is the source of truth.