Deploy: production proxy-trust chain unsolved — silently disables #144 HSTS and the #143 per-IP login limiter #260

Deployment-readiness gap (#244), BLOCKER — flagged independently by all 3 reviewers.

Problem

Behind any reverse proxy / edge (the production topology terminates TLS at an
edge and forwards plain HTTP to the container), the app never learns the original
request was HTTPS or who the real client is unless the immediate proxy is
trusted. Two already-"hardened" controls silently break when the trusted-proxy
list is empty:

• Security: forwarded headers, HSTS, CSP + security headers, pinned AllowedHosts #144 HSTS + HTTPS redirect become inert. ForwardedHeaders clears the
  framework defaults and honours X-Forwarded-Proto/X-Forwarded-For only
  from networks listed in RateLimiting:TrustedProxies
  (Program.cs:243-247).
  With nothing trusted, Request.IsHttps == false on every request (the
  proxy→container hop is plain HTTP), so app.UseHsts() short-circuits and never
  emits Strict-Transport-Security, and app.UseHttpsRedirection() is a no-op
  (ASPNETCORE_URLS=http://+:8080 only).
• Security: rate limiting on anonymous auth endpoints (login/refresh) #143 per-IP auth rate limiter collapses to one global bucket. The limiter
  keys on context.Connection.RemoteIpAddress
  (Program.cs:297), which is now
  the proxy's single IP — identical for every visitor. One attacker exhausts the
  global 10-logins-per-15-min budget and locks out every real user.

The compose stack already ships a sane default (TRUSTED_PROXY_CIDR=172.16.0.0/12
in deploy/.env.example + docker-compose.yml); the gap is that a real deploy
must set the correct immediate-proxy CIDR for its edge, and leaving it empty is
unsafe.

Fix (app-side, portable)

The app already reads the trusted-proxy list from config — keep that, and make an
empty TrustedProxies fail loud in Production (refuse to serve with inert
HSTS / a collapsed limiter) so a misconfigured deploy can't silently ship without
the controls. The concrete CIDR for the chosen edge is deploy-repo config.

Verify

• curl -I https://<prod> shows Strict-Transport-Security.
• A forged X-Forwarded-For from a non-proxy peer is ignored.
• Two distinct clients hit two distinct login buckets (11 logins from client A
  does not 429 client B).

Part of the #244 deployment-readiness audit; tracked in epic #15.