Let the login throttle see real client IPs behind Cloudflare

Behind a proxy REMOTE_ADDR is the proxy, so the per-IP limit would lump
every visitor together. New optional CLIENT_IP_HEADER in config.php
(e.g. 'CF-Connecting-IP') tells the throttle which header carries the
real address; invalid or absent values fall back to REMOTE_ADDR, and
configs that predate the setting behave as before. Only for origins
unreachable except through the proxy — documented in the README, which
also covers the mod_remoteip/real_ip alternative.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SePf61iazhCLJBefdRLBDm

README.md

@@ -251,6 +251,13 @@ returned as JSON, with detail gated behind `DEBUG`.
   IP, inside 15 minutes answer `429` until 15 minutes have passed since the
   last failure. A successful login clears the username's failures; stale rows
   are purged as new ones are recorded.
+- **Behind Cloudflare** (or any proxy that hides the visitor), the IP the
+  throttle sees is the proxy's. Either restore real client IPs at the web
+  server (Apache `mod_remoteip` / Nginx `real_ip` with `CF-Connecting-IP` —
+  the better fix, it also corrects your logs), or set
+  `CLIENT_IP_HEADER` to `'CF-Connecting-IP'` in `config.php`. Only do either
+  if the origin is unreachable except through the proxy; otherwise the header
+  can be spoofed to dodge the per-IP limit.
 - The shipped `.htaccess` (Apache) denies direct access to `videos/`,
   `includes/`, `config.php` and `schema.sql` — without it, video URLs would
   bypass login entirely. Nginx setups need the equivalent `location` blocks,