Log the client address next to the peer address (closes #270)

The access log, the rate-limit rejection lines, the CSRF warning and
the receiver's "webhook request received" line now carry clientIP,
the address the rate limiters key on, next to remoteIP, the
connecting peer. Logging works it out once per request from the same
code the rate limiters use and stores it on the request context for
the other lines. The CSRF and receiver lines name the peer as
remoteIP instead of remote_addr. The README documents the field and
that it is only as trustworthy as TRUSTED_PROXIES.

Model: opus-5-5

README.md

@@ -457,6 +457,19 @@ Your proxy must therefore **append** the peer address to
 `option forwardfor`, Caddy and AWS ALB by default), and must append a
 bare address with no port.
 
+Every log line that names a client carries two addresses: `remoteIP`,
+the connecting peer, which behind a proxy is the proxy; and `clientIP`,
+the client the rate limiters identify by the rules above, which is the
+field to read when tracing who sent what. Those lines are the
+`http request` access log line, the rate-limit rejection lines
+(`login failure limit exceeded` among them), the
+`csrf: token validation failed` warning and the receiver's
+`webhook request received` line. `clientIP` is only as trustworthy as
+`TRUSTED_PROXIES`: for a request from a peer inside the list, it is
+read out of the `X-Forwarded-For` that peer sent, so a peer that does
+not belong in the list can make it name any address it likes. For a
+request from any other peer, both fields name the peer.
+
 #### Sessions
 
 Sessions are bounded by two independent clocks, and end at whichever
@@ -841,9 +854,9 @@ reports.
    was given, so on any port other than 443 `$host` makes every form
    POST — including login — fail with `403 origin invalid`, with
    nothing in the error naming the cause.
-5. **Keep the proxy's access log.** webhooker's own access log records
-   the peer address, which behind a proxy is always the proxy. The
-   proxy's log is the only record of which client sent what. nginx's
+5. **Keep the proxy's access log.** webhooker's own access log names
+   the client in its `clientIP` field only while `TRUSTED_PROXIES`
+   covers the proxy; the proxy's log names it regardless. nginx's
    default `combined` format already logs `$remote_addr`; do not
    replace it with one that drops the client address, and retain those
    logs as long as you would want to answer a question about traffic.
@@ -872,9 +885,8 @@ server {
     # webhooker's message.
     client_max_body_size 1m;
 
-    # $remote_addr is the client. webhooker's own log records this
-    # proxy and nothing else, so this file is the only place the
-    # client's address is written down.
+    # $remote_addr is the client. webhooker's own log names it, as
+    # clientIP, only while TRUSTED_PROXIES covers this proxy.
     access_log /var/log/nginx/webhooker.access.log combined;
 
     location / {
@@ -2473,20 +2485,20 @@ trade.
 Net: **one `INFO` line per request, of at most 2,560 bytes.** That
 ceiling is arithmetic, not an observation: 3 × (512 + 11) for `url`,
 `useragent` and `referer`, plus 128 + 11 for `request_id`, plus 32 + 11
-for `method`, plus a 336-byte fixed portion (the field names, the
-punctuation, both timestamps at their longest, an IPv6 `remoteIP` with
-a zone, the status and the latency) — 2,087 bytes, stated at 2,560 so
-the figure has headroom. `internal/middleware/accesslog_test.go`
-asserts it against 8 KB of client-chosen text in the path, in the
-query, and in each of `User-Agent`, `Referer` and `X-Request-Id`,
+for `method`, plus a 405-byte fixed portion (the field names, the
+punctuation, both timestamps at their longest, `remoteIP` and
+`clientIP` each charged as an IPv6 address with a zone, the status and
+the latency) — 2,156 bytes, stated at 2,560 so the figure has headroom.
+`internal/middleware/accesslog_test.go` asserts it against 8 KB of
+client-chosen text in the path, in the query, and in each of
+`User-Agent`, `Referer`, `X-Request-Id` and `X-Forwarded-For`,
 including cases built from the characters the handlers escape, and
-against the widest access log line the service can be made to write: a
-5xx that keeps its concrete path while all three header fields are also
-at their budget. Every case runs through both handlers
-`internal/logger` can select — the JSON one and the text one it installs
-on a tty — since the two do not escape alike and the ceiling is quoted
-unqualified. Measured over a real connection, the widest access log line
-is 1,972 bytes.
+against a 5xx that keeps its concrete path while all three header fields
+are also at their budget and an `X-Forwarded-For` sent from a trusted
+proxy ends in an IPv6 client address at its longest. Every case runs
+through both handlers `internal/logger` can select — the JSON one and
+the text one it installs on a tty — since the two do not escape alike
+and the ceiling is quoted unqualified.
 
 Multiply that ceiling by the request rate to size log storage. Note
 that the rate is not bounded by the limits above on every route:
@@ -2824,9 +2836,9 @@ remedies are to block the source at the reverse proxy, or to
 rate-limit `POST /pages/login` there — the one place a limit can be
 applied without reintroducing the lockout, because the proxy sees the
 real client address. `TRUSTED_PROXIES` does not stop the saturation.
-The flood's source is in the proxy's access log: webhooker's own logs
-record the proxy's address, not the client's (see
-[Deployment behind a reverse proxy](#deployment-behind-a-reverse-proxy)).
+The flood's source is in the `clientIP` field of webhooker's access
+log while `TRUSTED_PROXIES` covers the proxy, and in the proxy's own
+access log either way (see [Trusted proxies](#trusted-proxies)).
 
 Finer-grained per-webhook rate limits (configured in the web UI and
 enforced in the webhook handler) can layer on top of this env-level
@@ -3064,7 +3076,7 @@ Applied to all routes in this order:
    (HSTS, X-Content-Type-Options, X-Frame-Options, CSP, Referrer-Policy,
    Permissions-Policy)
 3. **Logging** — Structured request logging (method, URL, status,
-   latency, remote IP, user agent, request ID)
+   latency, remote IP, client IP, user agent, request ID)
 4. **Metrics** — Prometheus HTTP metrics (if `METRICS_USERNAME` and
    `METRICS_PASSWORD` are both set)
 5. **CORS** — Cross-origin resource sharing headers