Harden the Cloudflare edge, trusted proxy chain, and abuse limits

[Vinosaamaa]

Parent

#107 (identified by #238)

What to build

Harden Chanter's public edge and abuse controls. Client identity must come only from trusted proxies, expensive or sensitive endpoints must have distributed limits, browser defenses must be explicit, and the origin must not be reachable by bypassing Cloudflare controls.

Acceptance criteria

• The gateway accepts Cloudflare/origin forwarding headers only from configured trusted proxies and discards spoofed client X-Forwarded-* or identity headers.
• Rate limits are distributed and cover authentication, registration/reset, invitations, messaging, search, uploads/downloads, AI, billing, reports, and admin actions with user/IP/tenant-aware keys.
• Signup and recovery flows can require Turnstile or equivalent bot proof without making accessibility or provider outages an account lockout.
• Cloudflare WAF/rate-limit rules, DDoS posture, DNSSEC, TLS mode, origin authentication/firewall policy, and WebSocket heartbeat/timeout behavior are documented and tested.
• Gateway/frontend emit a reviewed CSP, HSTS, frame, referrer, permissions, content-type, cache, and CORS policy; production has no wildcard credentialed origin.
• Payload/body/time/concurrency limits prevent oversized, slow, fan-out, AI-cost, and storage-cost abuse while returning stable retry guidance.
• Security events are correlated and alertable; blocked requests never include credentials or sensitive content in logs.
• Tests cover forwarded-header spoofing, multi-instance limits, WebSocket reconnects, CORS/CSRF, security headers, origin bypass, and denial-of-wallet scenarios.

Blocked by

• Ship transactional email and durable secure browser sessions #242
• Provision reproducible staging and production infrastructure #243

[Vinosaamaa]

Launch follow-up from #242 / PR #312: bound per-user active browser sessions and the sessions/devices response through a reviewed creation cap or pagination, coordinated with distributed login/registration limits. Keep the successful-password verification outside the per-user row lock, and cover concurrent session creation at the limit. The current list is authorization-scoped but not paginated; this remains pre-launch capacity/abuse work.