Warn when production shares one rate-limit bucket (closes #149)

With TRUSTED_PROXIES empty, every rate limiter keys on the connecting
peer. Production runs behind a TLS-terminating reverse proxy, so the
peer is that proxy for every request and all clients share one bucket
per limit. For the login limiter that means any remote client sending
five POSTs a minute holds the only administrative login at HTTP 429.

The empty default is correct — trusting forwarded headers from
arbitrary peers lets any client choose its own bucket — so this makes
the consequence visible rather than changing the keying, the limits or
the default:

- config logs a WARN at startup when the environment is prod and
  TRUSTED_PROXIES is empty, naming the variable, the shared bucket and
  the deniable admin login.
- The security-feature bullet's "per IP" login claim is now conditional
  on TRUSTED_PROXIES, which is the only case where it holds.
- The rate-limiting section separates the receiver case (sharing costs
  throughput, the safe direction) from the login case (sharing costs
  availability of the only admin path, not safe).
- The trusted-proxies configuration section states the consequence and
  names TRUSTED_PROXIES as the remedy.

README.md

@@ -96,7 +96,7 @@ TTY detection, and security headers are always applied.
 | `RETENTION_SWEEP_INTERVAL` | How often the retention reaper and archive sweeper run (Go duration, must be positive) | `1h` |
 | `SESSION_IDLE_TIMEOUT`  | Idle session timeout (Go duration)  | `24h`    |
 | `RECEIVER_RATE_LIMIT`   | Receiver requests/minute per IP per entrypoint (10x that per IP across the route) | `120` |
-| `TRUSTED_PROXIES`       | CIDRs whose forwarded headers are trusted | `""` (none) |
+| `TRUSTED_PROXIES`       | CIDRs whose forwarded headers are trusted (unset: all clients behind a proxy share one rate-limit bucket) | `""` (none) |
 
 #### Trusted proxies
 
@@ -115,6 +115,23 @@ or draining someone else's. Set it to the address of your reverse
 proxy, and to nothing wider. A set but unparseable value aborts
 startup.
 
+That default is safe against forged headers, but leaving it unset in
+production has a cost you must know about. Production runs behind a
+TLS-terminating reverse proxy, so with `TRUSTED_PROXIES` unset every
+request keys on the proxy's own address and all clients share a single
+bucket per limit. For the login and password-change limits that is a
+denial of service anyone can perform: a steady five POSTs per minute
+from any address on the internet keeps the shared login bucket full,
+and the operator's own login then returns HTTP 429 for as long as the
+trickle continues. There is no second administrative path and no
+bypass. Restarting the service clears the in-memory buckets, but a
+sustained trickle re-locks them immediately.
+
+The remedy is to set `TRUSTED_PROXIES` to your reverse proxy's
+address, which restores per-client buckets. webhooker logs a warning
+at startup when `WEBHOOKER_ENVIRONMENT=prod` and `TRUSTED_PROXIES` is
+empty. See [Rate Limiting](#rate-limiting) for what each limit shares.
+
 `X-Real-IP` and `True-Client-IP` are **never** read, from any peer.
 Reverse proxies append to `X-Forwarded-For` but forward other client
 headers verbatim, so a single-valued header is client-controlled even
@@ -890,16 +907,29 @@ connection's own address, unless the peer is listed in
 `TRUSTED_PROXIES`, in which case the forwarded client address is used
 instead. See [Trusted proxies](#trusted-proxies). Deployed without that
 variable set, a client behind a reverse proxy shares one bucket with
-every other client behind the same proxy, which is the safe direction
-to be wrong in: set `TRUSTED_PROXIES` to the proxy's address to get
-per-client limits back. That shared bucket matters more for the
-aggregate limit than for the per-entrypoint one: with `TRUSTED_PROXIES`
-unset behind the reverse proxy a production deployment is required to
-run behind, every request keys on the proxy, so the aggregate limit
-becomes a service-wide ceiling of 1200 requests per minute across all
-senders and all entrypoints, where the per-entrypoint limit's capacity
-still grows with the number of entrypoints. Any deployment with more
-than a handful of busy entrypoints must set `TRUSTED_PROXIES`.
+every other client behind the same proxy. Set `TRUSTED_PROXIES` to the
+proxy's address to get per-client limits back. What the shared bucket
+costs is not the same for every limiter, and the two cases pull in
+opposite directions:
+
+- For the **receiver** limits it costs throughput, which is the safe
+  direction to be wrong in: sharing can only make a limit bind sooner,
+  never let a sender past it. It matters more for the aggregate limit
+  than for the per-entrypoint one: with `TRUSTED_PROXIES` unset behind
+  the reverse proxy a production deployment is required to run behind,
+  every request keys on the proxy, so the aggregate limit becomes a
+  service-wide ceiling of 1200 requests per minute across all senders
+  and all entrypoints, where the per-entrypoint limit's capacity still
+  grows with the number of entrypoints. Any deployment with more than a
+  handful of busy entrypoints must set `TRUSTED_PROXIES`.
+- For the **login and password-change** limits it costs availability of
+  the only administrative path, which is not safe at all. Five POSTs
+  per minute from any address on the internet keeps the single shared
+  login bucket full, and the operator's own login returns HTTP 429 for
+  as long as that trickle continues. A restart clears the in-memory
+  buckets and a resumed trickle re-locks them. Production deployments
+  must set `TRUSTED_PROXIES`; webhooker warns at startup when it is
+  empty in `prod`.
 
 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
@@ -1118,8 +1148,11 @@ downstream at form-parse time.
   (custom HTTP transport with SSRF-safe dialer that validates resolved
   IPs before connecting, preventing DNS rebinding attacks)
 - **Login rate limiting** via [go-chi/httprate](https://github.com/go-chi/httprate):
-  per-IP sliding-window rate limiter on the login endpoint (5 POST
-  attempts per minute per IP) to prevent brute-force attacks
+  sliding-window rate limiter on the login endpoint, 5 POST attempts
+  per minute per bucket, to slow brute-force attacks. The bucket is per
+  client IP only when `TRUSTED_PROXIES` names the reverse proxy;
+  unset, every client shares one bucket and the login becomes remotely
+  deniable (see [Rate Limiting](#rate-limiting))
 - Prometheus metrics behind basic auth
 - Static assets embedded in binary (no filesystem access needed at
   runtime)