docs: REMOTE_URL includes /mcp, and the entrypoint skips silently where the feeder exits 1

Two details needed before the first client flip.

1. MEMPALACE_REMOTE_URL is the full endpoint including /mcp with no trailing
   slash. The feeder POSTs to it verbatim (bin/mempalace-pi-session:718), and the
   server matches `path != "/mcp"` exactly, so a base URL or a trailing slash
   both 404 -- and a 404 here looks like a routing/proxy fault, not a config
   typo, which is a bad hour to spend. Matches the existing pi-devbox examples.
   For this fleet: https://mempalace.jordbo.se/mcp

2. The 3.7 trap has TWO symptoms, not one, and I had only documented the loud
   one. Direct runs / session-end / cron exit 1 with a clear error (:298-300).
   But pi-devbox's entrypoint-user.sh:134 checks the same condition and skips
   *quietly* -- and the skip happens before the subshell that writes
   ~/.pi/agent/mempalace-catchup.log, so there is not even an empty log to find.
   A container flipped with REMOTE_URL but no SSH_TARGET therefore contributes
   nothing to the palace and leaves no artifact explaining why. The skip is
   correct in itself (there is genuinely no inbox to ship to) but it is
   indistinguishable from a healthy run with nothing to do. Documented with two
   commands that tell those apart after a flip.

docs/phase-1-exposure-runbook.md

@@ -289,9 +289,35 @@ failing — the loudest symptom is silence, which is the hardest kind to notice.
 - **HTTPS first, mining later:** set the URL and token, and pin the feeder to `--mode local` until the SSH
   target exists. Tools then read/write the shared palace while transcripts keep landing in the local one.
 
+`MEMPALACE_REMOTE_URL` is the **full endpoint including `/mcp`, with no trailing slash** — the feeder POSTs
+to it verbatim (`urllib.request.Request(url, data=payload, …)`, `:718`), and §3.5 shows the server matches
+`/mcp` exactly. Matches the existing examples (`docker-compose.mempalace.yml:7`,
+`MEMPALACE_REMOTE_URL=http://<reachable-host>:8765/mcp`). For this fleet:
+`MEMPALACE_REMOTE_URL=https://mempalace.jordbo.se/mcp`
+
 Either way, run the feeder once by hand and read its exit code before trusting the timer. This is
 precisely the failure "one machine first" is meant to contain.
 
+**The same misconfiguration has two different symptoms depending on who invokes the feeder** — checked in
+the code 2026-08-12, and the quieter one is the trap:
+
+| Caller | Behaviour with `REMOTE_URL` set and `SSH_TARGET` unset |
+| --- | --- |
+| direct run, session-end hook, cron | `exit 1` with `error: MEMPALACE_PI_SSH_TARGET unset` (`:298-300`) |
+| **pi-devbox container start** | **silently skips — no error, no log file** (`entrypoint-user.sh:134`: `: # remote palace but no inbox configured — nothing we can ship to; skip quietly`) |
+
+The entrypoint's skip happens *before* the subshell that writes
+`~/.pi/agent/mempalace-catchup.log`, so there is not even an empty log to notice. Someone asking "why is
+nothing from this container in the palace?" finds no artifact at all. The skip is deliberate — there is
+genuinely nothing to ship to — but it is indistinguishable from a healthy run that had nothing to do.
+
+→ On a pi-devbox container, confirm the feeder is actually alive after a flip rather than assuming:
+
+```sh
+mempalace-pi-session --reason manual-check; echo "exit=$?"   # exit=0 and a filed count, not silence
+cat ~/.pi/agent/mempalace-catchup.log                        # missing file = the entrypoint skipped
+```
+
 ---
 
 ## 4. Still open