Problem

After #20097, auth.mode=trusted-proxy + bind=loopback is allowed (good), but misconfigured gateway.trustedProxies values (for example only 10.0.0.1) can still make auth fail in confusing ways for same-host proxy setups.

Fix

• In runtime config validation, when auth.mode=trusted-proxy and resolved bind is loopback, require gateway.trustedProxies to include a loopback proxy address (127.0.0.1, ::1, or loopback CIDR).
• Add tests for:
  • loopback trusted-proxy with ::1 (allowed)
  • loopback trusted-proxy with non-loopback trusted proxy IP (rejected)
• Update Trusted Proxy docs to reflect loopback-first same-host proxy setup guidance.

Verification

• pnpm vitest run src/gateway/server-runtime-config.test.ts

Follow-up hardening for #20097.

Greptile Summary

Adds runtime validation to prevent misconfigured gateway.trustedProxies from breaking auth in same-host proxy setups. When bind=loopback and auth.mode=trusted-proxy, the gateway now requires at least one loopback address (127.0.0.1, ::1, or a loopback CIDR) in the trusted proxy list.

The implementation leverages existing isTrustedProxyAddress CIDR-matching logic and includes comprehensive test coverage for both IPv4 and IPv6 loopback addresses, as well as rejection cases. Documentation correctly reflects the new requirement with clear guidance for same-host proxy configurations.

Confidence Score: 5/5

• This PR is safe to merge with no blocking issues
• The implementation is straightforward and defensive - it adds validation to catch a misconfiguration scenario early. The code correctly reuses existing CIDR-matching logic via isTrustedProxyAddress, includes comprehensive test coverage for both acceptance and rejection paths (covering 127.0.0.1, ::1, non-loopback addresses, and empty proxy lists), and follows the existing validation pattern. Documentation is properly updated to reflect the new requirement.
• No files require special attention

_{Last reviewed commit: 7cdbb65}