docs: why the tunnel and the feeder's SSH path are not redundant; newt done

Asked "why do we need Pangolin if you proposed rsync/ssh?", and the runbook did
not actually answer it -- it stated both were needed without saying why neither
substitutes. New section 1.3:

  - Pangolin/HTTPS carries the MCP tool surface (search, add_drawer,
    diary_write, kg_*) -- every live tool call, from any MCP client.
  - SSH/rsync carries transcript *files* only, because mempalace_mine expands
    its source path server-side, so the server can only mine its own disk.

HTTPS alone is a palace you can query but cannot feed; SSH alone is files with
no query API. The rsync is not a transport preference, it is a workaround for
where `mine` resolves paths.

Records honestly that `ssh -L 8765:172.17.0.1:8765 synlig` *would* replace the
tunnel for MCP, and why we don't: synlig dials out (reaching for a dial-out
tunnel is itself the evidence inbound was unavailable), MCP clients want a
durable URL rather than a per-session forward, and the forward must be up on
every device before every session.

And the design's weak point, stated instead of glossed: the rsync runs
client -> synlig, so mining needs synlig's SSH reachable *from the client*. Were
that true everywhere, no tunnel would be needed for MCP either. Honest
expectation after Phase 1 is therefore: query/write from anywhere, mine only
from devices that can reach synlig's SSH. Section 4 now carries the upstream ask
that would close the gap -- have the feeder send content over MCP (add_drawer /
diary_write, which it already calls) instead of asking the server to mine a path
it must first rsync there.

New section 3.7, a live trap for the imminent client flip:
MEMPALACE_REMOTE_URL on its own does not degrade to local feeding, it *stops*
feeding. auto mode switches to remote as soon as the URL is set (:286) and
remote mode then exits 1 without MEMPALACE_PI_SSH_TARGET (:298-300), before
anything is staged or filed -- so a cron feeder just starts failing, and the
loudest symptom is silence. Two safe orders given: set all three variables in
one edit, or set URL+token and pin --mode local until the SSH target exists.

newt is installed on synlig and connected to Pangolin (done 2026-08-12), marked
here and in the synlig runbook's item 2; the blocker is now item 3, the one
sudo. Added the follow-up that "connected to Pangolin" only proves newt reached
nyvaken -- reaching the *palace* is a separate claim that fails independently,
so probe 172.17.0.1:8765/healthz from inside newt's namespace.

All seven code citations verified against the source at commit time.

docs/synlig-primary-runbook.md

@@ -129,16 +129,20 @@ standing up a network-reachable service while you were asleep was not mine to de
 ## 4. Tomorrow, in order
 
 > **2026-08-12: items 1–2 and 5 now have their own runbook —**
-> [`phase-1-exposure-runbook.md`](./phase-1-exposure-runbook.md). Pangolin on nyvaken is updated (done).
-> newt is still missing on synlig. That doc also records why per-device Pangolin users are the wrong layer,
-> and an additional loopback finding: a loopback bind does not merely 403, it also silently starts the
-> server with **no token at all** (auto-minting is gated on the bind being non-loopback).
+> [`phase-1-exposure-runbook.md`](./phase-1-exposure-runbook.md). Pangolin on nyvaken is updated (done),
+> and **newt is now installed on synlig and connected to Pangolin (done 2026-08-12)** — so the blocker is
+> now item 3, the one `sudo`. That doc also records why per-device Pangolin users are the wrong layer, why
+> the HTTPS tunnel and the feeder's SSH path are **not** redundant (§1.3), the client-flip variable trap
+> (§3.7), and an additional loopback finding: a loopback bind does not merely 403, it also silently starts
+> the server with **no token at all** (auto-minting is gated on the bind being non-loopback).
 
 1. **Pangolin update on nyvaken** (yours). ✅ done 2026-08-12.
-2. **⚠️ synlig has no tunnel client.** `docker ps` shows only the Gitea runner and digikam — no `newt`.
-   Pangolin on nyvaken cannot reach synlig by itself; synlig needs a newt container (or an equivalent
-   outbound tunnel) added. Easy to miss because Pangolin will look healthy on its own side. If newt runs
-   in Docker here, the docker0 bind above is already correct for it.
+2. ~~**⚠️ synlig has no tunnel client.**~~ ✅ **done 2026-08-12** — newt installed and connected to Pangolin.
+   (Kept for the reasoning: `docker ps` showed only the Gitea runner and digikam. Pangolin on nyvaken
+   cannot reach synlig by itself; synlig had to dial out. Easy to miss because Pangolin looks healthy on
+   its own side — which is also why "connected" is not yet proof it can reach the palace: verify
+   `172.17.0.1:8765/healthz` from *inside* newt's namespace, exposure runbook §3.3.) Since newt runs in
+   Docker here, the docker0 bind above is already correct for it.
 3. **One sudo, then start** (the unit is already staged; just drop the suffix):
    ```sh
    sudo loginctl enable-linger ecsjper