feat(api): capture client connection info via ConnectInfo

[ymh1874]

Closes #358.

What this does

Starts capturing client connection information (the client IP) in request processing, as the enabling step for a future IP-based login-control feature. The lockout/rate-limit mechanism itself is out of scope here — this is the plumbing that makes the client address available to handlers and middleware.

• Switches the public listener's make-service to into_make_service_with_connect_info::<SocketAddr>(), so the raw TCP peer address is stored in a ConnectInfo<SocketAddr> request extension.
• Surfaces it on the existing request tracing span as a client.addr field (reusing the previously-empty placeholder slot), so the capture is verifiable in request logs.

Mirrors Python Keystone

This deliberately follows how upstream Python Keystone captures the client address:

Python	This PR
WSGI REMOTE_ADDR / flask.request.remote_addr (raw peer when no proxy parsing applies)	ConnectInfo<SocketAddr>
remote_addr surfaced in the auth-failure log line	client.addr field on the request span
Proxy-header parsing kept separate, config-gated via [oslo_middleware] enable_proxy_headers_parsing (default off)	deliberately deferred — see follow-up below

Python captures a single REMOTE_ADDR at the WSGI front door; the analogue here is the public HTTP interface. The internal (SPIFFE mTLS/TCP) and admin (SPIFFE mTLS/UDS) interfaces are intentionally not covered: they bypass axum::serve, and a Unix socket has no meaningful SocketAddr.

Important: raw peer only — not proxy-aware

The captured address is the raw TCP peer. Behind a reverse proxy / load balancer (the normal production topology) it is the proxy's address, not the real client. It must not be used directly for IP-based login control until a trusted forwarded-header layer exists.

Required follow-up (after this merges)

A config-gated forwarded-header layer that parses X-Forwarded-For / RFC 7239 Forwarded, mirroring Python's [oslo_middleware] enable_proxy_headers_parsing — off by default, so a deployment that is not actually behind a trusted proxy cannot be tricked into trusting a spoofed header. (axum-client-ip is a candidate, or a hand-rolled middleware.) This is required before any IP-based login control is built on top of this capture.

Composition with #734

Issue #734 wraps the router with NormalizePathLayer from the outside, so the public listener serves a NormalizePath<Router>, not a plain Router. into_make_service_with_connect_info is available on the same axum::ServiceExt trait already in use (blanket impl for any Service), so it applies directly — no restructuring needed.

Tests

Added connect_info_is_captured_and_normalizes, which drives the exact production make-service path fully in-process and asserts a /echo/ request both normalizes the trailing slash and delivers the injected peer address to the handler — proving #358 and #734 compose. The existing trailing_slash_is_normalized regression still passes.

[gtema]

Nice, but would need a followup

[gtema]

This need to be addressed of course as well. Follow-up should be absolutely fine

[gtema]

this is an interesting point. I agree for spiffe we currently go absolutely different way, but it should be possible to capture the information there as well. You can definitely capture the remote IP address and at a later phase the headers (for x-forward) should be also available. Please evaluate this in the followup