docs: proxy target is http:// not https://; loopback probe refuses, it does not 403

Both corrections come from the first real Phase 1 start on synlig (2026-08-12).

1. The Pangolin resource target was documented as bare `172.17.0.1:8765` with no
   scheme, and the obvious guess from that is `https://` -- which cannot work.
   `contrib/systemd/mempalace-serve.service` runs `serve --host 172.17.0.1
   --port 8765` with no --tls-cert, so the primary speaks plaintext HTTP; TLS
   terminates at Pangolin, which is the whole point of the RFC 6.2 decision.
   Point a proxy at https:// and it attempts a TLS handshake against a plaintext
   listener: 502 from outside, while `curl 172.17.0.1:8765/healthz` on the box
   still says ok -- a confusing pair of symptoms. Now spelled `http://` with the
   failure mode named, in the runbook and in the unit's comments.

2. `curl -s 127.0.0.1:8765/healthz` was documented as "expect 403". Wrong: the
   real run returns empty. With a docker0-only bind nothing is listening on
   loopback, so the connection is refused at TCP level before any header is sent
   (%{http_code} -> 000, exit 7). The 403 is the *loopback-bind* case verified
   2026-08-10 -- server on 127.0.0.1 answering a proxy-forwarded foreign Host.
   Two distinct behaviours had been collapsed into one expectation in three
   places (both runbooks and the unit).

   Worth stating why the correction matters rather than just fixing it: refusal
   is the *stronger* signal. A 403 proves only that a request was rejected; a
   refused connection proves the loopback and LAN surface is not listening at
   all. Someone who expected 403, saw silence, and "fixed" it by rebinding to
   0.0.0.0 would have converted a correct configuration into an exposed one.
   The docs now also say what to do if it hangs, or if ss shows 0.0.0.0:8765.

docs/synlig-primary-runbook.md

@@ -143,14 +143,21 @@ standing up a network-reachable service while you were asleep was not mine to de
    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):
+3. **One sudo, then start** (the unit is already staged; just drop the suffix). ✅ **done 2026-08-12** —
+   linger enabled, unit enabled, `172.17.0.1:8765/healthz` → `ok`.
    ```sh
    sudo loginctl enable-linger ecsjper
    cd ~/.config/systemd/user && mv mempalace-serve.service.staged mempalace-serve.service
    systemctl --user daemon-reload && systemctl --user enable --now mempalace-serve
    curl -s 172.17.0.1:8765/healthz          # ok
-   curl -s 127.0.0.1:8765/healthz           # 403 — expected, not a bug (§2.4)
+   curl -s 127.0.0.1:8765/healthz           # NOTHING — refused, exit 7 (not 403; see below)
+   ss -ltnp | grep 8765                     # 172.17.0.1:8765 only
    ```
+   ⚠ **Corrected 2026-08-12:** this line predicted `403`. The real run returned empty, which is *more*
+   reassuring. With the docker0-only bind nothing listens on loopback, so the connection is refused before
+   any header is sent (`%{http_code}` → `000`, `$?` → `7`). The 403 in §2.4 is the **loopback-bind** case:
+   a server on `127.0.0.1` answering a proxy-forwarded foreign `Host:`. Two different failures that were
+   collapsed into one expectation here.
 4. **Collect the shared token** (auto-minted on first non-loopback start, stable across restarts):
    ```sh
    cat ~/.mempalace/server/f5d849287f6d73f0141b29d7/token