Point to the proxy's access log for a login flood's source

No log line records the client address taken from X-Forwarded-For,
so the login endpoint section no longer says the source shows in the
failure logs; it names the proxy's access log instead.

Model: opus-5-5

README.md

@@ -2722,9 +2722,10 @@ re-fills both verification slots on its first two requests. The
 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,
-but when it covers the proxy the source is visible in the failure logs,
-and the default covers a proxy on a private network.
+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)).
 
 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