Say the proxy is covered by default or by a set value

The rate-limit test comments on trustedProxyCIDR and forwardedKeyFor
said production needs TRUSTED_PROXIES set; another said only
operator-listed addresses are trusted. The README's Rate Limiting
paragraph said "listed in", and the login endpoint section assumed
every proxied deployment shares one bucket. All now match the
RFC 1918 default.

Model: opus-5-5

README.md

@@ -2552,7 +2552,7 @@ arrived uncut — never the numbers.
 
 Every limiter here — receiver, login, and password change — identifies
 the client the same way, through one shared key function: the
-connection's own address, unless the peer is listed in
+connection's own address, unless the peer is inside
 `TRUSTED_PROXIES`, in which case the forwarded client address is used
 instead. That address becomes a bucket by family: IPv4 keys on the full
 address, IPv6 on its `/64` prefix. A routed `/64` is the normal
@@ -2590,7 +2590,8 @@ opposite directions:
 
 The login `POST` is the one endpoint with no pre-emptive limiter in
 front of it, and that is deliberate. A limiter that spends budget on
-arrival is a lockout in this deployment shape: sharing one bucket, a
+arrival is a lockout wherever clients share one bucket, as they do
+behind a reverse proxy that `TRUSTED_PROXIES` does not cover: a
 stranger sending five POSTs a minute — about 0.08 requests per second,
 from anywhere — keeps it permanently full, and the operator has no
 second administrative path. So the handler inverts the order: