Key the client address on the connection, not a header the caller sends

client_ip() read the first X-Forwarded-For hop unconditionally. The
login rate limit and the account lockout are keyed on that value and the
audit log records it, so rotating the header per request bought an
unbounded budget and an untraceable trail.

This walked around TRUSTED_PROXY_COUNT, which exists to decide exactly
this. The app leaves ProxyFix off by default and says why, ten lines of
comment away: ProxyFix trusts X-Forwarded-*, a client can send those
itself, and the login limiter is keyed on the address. Then client_ip
read the header anyway, so the stated protection never applied.

Resolution is now from remote_addr, which ProxyFix has already filled
from the header wherever a proxy is genuinely configured. Both cases end
at the same trustworthy source, and the port still comes off because ARR
forwards clientip:port and ProxyFix passes it through verbatim.

geenforce and tools had each hand-rolled the same mistake for their own
limiters. Rather than duplicate security-relevant logic a third time,
client_ip and strip_port join the shopdb.api surface (contract 0.28.0).
geenforce's _trusted_client_ip, which already refused the raw header for
its IP allowlist, is untouched and was the model for this.

The stability table was also missing rows for 0.26.0 and 0.27.0.

INSTALL-WINDOWS-IIS.md never mentioned TRUSTED_PROXY_COUNT, so a site
installed from it runs behind IIS with the setting at 0: every request
looks like it came from IIS, the whole site shares one rate-limit
bucket, and the audit log records the proxy for every action. It now
says so, and says not to set it when nothing is in front.

Three test modules simulated separate callers by setting
X-Forwarded-For, which is the header a real attacker rotates to escape
the limit. One of them, test_client_ip_prefers_forwarded_first_hop_
stripped, asserted the defect outright. The suite could not have caught
this. They now drive REMOTE_ADDR, with a regression guard that forging
the header buys nothing.

Scope: product

CHANGELOG.md

@@ -154,6 +154,19 @@ ADR-007 and ADR-002.
   refresh token that minted new ones for thirty days. `/api/auth/refresh` and
   the API-token path already checked `isactive`; the loader now does too.
 
+- **The login rate limit could be reset by a header the caller writes.**
+  `client_ip()` read the first `X-Forwarded-For` hop unconditionally, so
+  rotating it per request bought an unbounded budget, and every audit row
+  recorded the forged address. This walked around `TRUSTED_PROXY_COUNT`, which
+  exists to decide whether a proxy is really in front: the app deliberately
+  leaves ProxyFix off by default for exactly this reason, and then read the
+  header anyway. Resolution is now from `remote_addr`, which ProxyFix has
+  already filled from the header where a proxy is configured. Two plugins had
+  hand-rolled the same mistake for their own limiters and now share the helper,
+  which is on `shopdb.api` so the third one does not. **A site behind IIS must
+  set `TRUSTED_PROXY_COUNT`** or its whole floor shares one rate-limit bucket;
+  INSTALL-WINDOWS-IIS.md now says so.
+
 - **The published site's API documentation page had no spec to show.**
   `shopdb/core/api/docs.py` reads `docs/openapi.json` at runtime to serve
   `/api/docs`, and publication excluded the whole of `docs/` because the prose