fix trusted client IP in HTTP authentication

[PokAhonTAS911]

Description

Fixes #2327.

HTTP request logging and login protection already resolve the client address through get_client_ip(), which honors trusted X-Forwarded-For headers and cluster forwarding. HTTP auth-state creation still passed req.remote_addr() directly, so per-user allowed IP ranges were evaluated against the reverse proxy address even while the network status page showed the forwarded client address.

This change:

• resolves the trusted client IP before creating an HTTP auth state
• uses the same resolved IP in password and SSO authentication-failure audit events
• keeps the existing safe fallback: when forwarded headers are not trusted, get_client_ip() returns the socket peer address

The existing warpgate-common-http::request tests cover both trusted forwarded headers and the untrusted fallback.

Validation

• cargo check -p warpgate-protocol-http --tests
• cargo test -p warpgate-common-http request::tests
• cargo test -p warpgate-protocol-http --lib
• cargo clippy -p warpgate-protocol-http --tests -- -D warnings
• rustfmt check for all changed files

AI Usage

Choose the level of AI involvement for this PR.

• Fully vibe coded
• AI-designed, AI-coded, manually checked
• Human-designed, AI-coded
• Human-designed, human-coded (includes AI autocompletions and boilerplate gen)

_{This is not to block AI contributions but rather to speed up PR review (saves time on trying to deduce the logic behind AI hallucinations).}