Resolve client identity only from trusted proxies

[HC-ONLINE]

Pull Request Template

Description

Resolve the client identity used by the rate limiter and auth log attribution from the
connection peer instead of trusting X-Forwarded-For unconditionally. Previously any API
caller could rotate the header to mint fresh rate-limit buckets (bypassing the limit
entirely) or forge a victim's address to consume its quota.

The header is now honoured only when the connection peer is declared in the new
api.trusted_proxies setting (default [], i.e. the header is always ignored): the chain
is walked right-to-left with ipaddress validation, malformed hops fail closed, IPv4-mapped
forms are normalized and an unparseable peer collapses to the shared unknown bucket.
Both launch paths start Uvicorn with proxy_headers=False, so forwarded headers can never
rewrite the peer before the policy runs and FORWARDED_ALLOW_IPS is irrelevant to client
identification. The rate-limit middleware and auth log attribution share one resolver.
Configuration entries are validated when the config is built: catch-all networks
(0.0.0.0/0, ::/0, IPv4-mapped /96), IPv6 zone identifiers and invalid values are
rejected; host bits are masked with a warning.

Validation: tests/unit 1731 passed / 3 skipped, tests/integration/api 57 passed,
ruff check ., ruff format and pyright clean. A mutation check confirmed that all 9
security regression tests fail against the previous implementation while functional tests
still pass.

Related Issue

No linked issue (no public issue tracker entry for this change).

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Checklist

• I have followed the style guidelines of this project (Ruff & Pyright)
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have updated the documentation accordingly

Screenshots (if applicable)

Not applicable — backend/security behaviour only; no UI changes.