fix(auth): address PR #617 review feedback on CSRF/rate-limit implementation

- Remove unreachable `&& !xsrfToken` condition from `handleFetch` guard;
  simplify the redundant `cookieParts.length > 0` check that follows it
- Add `TOO_MANY_LOGIN_ATTEMPTS` to both Error Handling sections in CLAUDE.md
  (backend and frontend) so LLMs are aware of the code without looking it up
- Add reverse-proxy IP trust and IPv6 address-cycling caveats to ADR-022
  Consequences section

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/adr/022-csrf-session-revocation-rate-limiting.md

@@ -104,3 +104,12 @@ source.
   because `@WebMvcTest` slices exclude `JacksonAutoConfiguration`. The response
   only serialises a fixed String key (`"code"`) so naming strategy and custom
   modules are irrelevant.
+- IP extraction uses `HttpServletRequest.getRemoteAddr()`. In deployments behind
+  a reverse proxy the `X-Forwarded-For` header is not trusted — doing so would
+  let clients spoof their IP and trivially bypass the per-IP limit. Trusting
+  proxy headers requires separate work (e.g. Spring's `ForwardedHeaderFilter`
+  with an allowlist of trusted proxy addresses).
+- IPv6 and IPv4-mapped addresses (e.g. `::ffff:1.2.3.4`) are not normalised to
+  a canonical form. An attacker with access to multiple IPv6 addresses could
+  rotate addresses to bypass the per-IP bucket. This is a known limitation of
+  address-based rate limiting and is acceptable for the current deployment.