feat(security): make auth-flow user scope independently enforceable (#506)

[ericfitz]

Summary

Closes #506.

The multi-scope auth-flow rate limiter (api/auth_flow_rate_limiter.go) enforced session, IP, and user scopes at the same 100/60s limit and checked them session → IP → user. Because single-IP traffic accumulates the IP counter at least as fast as the user counter, the IP scope (checked first, at an equal limit) always tripped first — so the user scope could never be the attributed blocker for real single-IP traffic. It was effectively subsumed by the IP scope.

Change (issue options 1 + 2)

• Differentiate the limits — per-user limit is now 50/60s, half the per-IP limit (100/60s). The user scope now bites independently for single-account attacks (password-spray / account enumeration against one victim) from a single source IP.
  • Chose to lower the user limit rather than raise the IP limit (the issue's example): it is strictly more restrictive and can't lock out legitimate traffic — an interactive OAuth flow is a handful of requests, a client-credentials client with a 1h token needs ~1 request/hour, and ResetUserRateLimit clears the counter on successful login.
• Reorder to most-specific-first (session → user → IP) so the user scope is correctly attributed when it bites.
• Extract the three limits into named constants (authFlowSessionLimit, authFlowUserLimit, authFlowDefaultIPLimit).

Tests

• New regression test: a single account from a single IP is blocked by the user scope at 50, not subsumed by the IP scope at 100.
• Updated the user-scope unit tests and the TestAuthFlowRateLimiting_MultiScope integration sub-test to the new per-user limit.
• make lint, make build-server, make test-unit (2381 passed) all green.
• security-regression scan: PASS. security-review: no findings (change is strictly more restrictive; no new attack surface).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kk9GxWS9EpazjbwBKfMpUX