fix(gateway): forward the real client IP to the backend on every call

The backend recorded 172.19.0.9 — the gateway's own docker connection address — as
the client IP for all users: the account's last-login IP shown in the admin console,
and it never reached the backend access log. The gateway forwarded the client IP as
X-Forwarded-For only on chat/feedback calls; every other backend call (including the
profile fetch that stamps last_login_ip) sent none, so the backend fell back to the
peer address.

Carry the client IP on the request context (WithClientIP, mirroring WithPlatform) and
set it once per request in the Connect edge, so the backend client injects
X-Forwarded-For on every downstream REST call. Also add the resolved client IP to the
backend access log.

Test: WithClientIP rides a non-chat call (Profile) as X-Forwarded-For, and is absent
when no IP is set. Docs updated (ARCHITECTURE gateway↔backend + edge).

docs/ARCHITECTURE.md

@@ -151,7 +151,10 @@ dropped). Horizontal scaling is explicit future work.
   and GCG are unaffected** (they stay decoded concrete characters, §9.1).
 - **gateway ↔ backend (sync)**: plain HTTP REST/JSON. The gateway injects
   `X-User-ID` (and the session's trusted `X-Platform`, §3) for authenticated
-  requests; `backend` never re-derives identity or platform from the body. Because every sync call targets the one backend host, the
+  requests, plus the caller's real IP as **`X-Forwarded-For`** on **every** call
+  (carried on the request context), so the backend records the real caller — the
+  account's last-login IP, chat/feedback moderation, the access log — rather than
+  the gateway's own connection address; `backend` never re-derives identity or platform from the body. Because every sync call targets the one backend host, the
   gateway's REST client widens its keep-alive pool well past the stdlib default
   of 2 idle connections per host; otherwise the per-request connection churn
   exhausts ephemeral ports and burns gateway CPU under load (see
@@ -1496,7 +1499,8 @@ Two contours, two secret/variable prefixes (`TEST_` / `PROD_`):
   forwards the domain to `scrabble:80`, so the in-compose caddy serves plain HTTP
   (`CADDY_SITE_ADDRESS=:80`). The in-compose caddy **trusts X-Forwarded-For from
   private-range upstreams** (`trusted_proxies private_ranges`), so the real client IP —
-  used for chat-moderation logging and the gateway's per-IP rate limiting — survives the
+  used for the gateway's per-IP rate limiting and, forwarded on to the backend, the account's
+  last-login IP, chat/feedback moderation and the access log — survives the
   host-caddy hop; in prod (no host caddy) public clients are untrusted and Caddy uses the
   real peer, so the single config is correct and spoof-safe in both contours. The
   **bot-link mTLS material** (a private CA + gateway/bot leaves, CN=`gateway`) is