test: add integration coverage for the auth-flow rate limiter (multi-scope 429s)

[ericfitz]

Summary

The OAuth/SAML auth-flow rate limiter (multi-scope: session / IP / user) has no end-to-end integration coverage. TestAuthFlowRateLimiting_MultiScope exists but skips against the integration server, so only the unit tests in api/auth_flow_rate_limiter_test.go exercise the limiter. Add real integration coverage so the multi-scope 429 behavior is verified against a running server.

Follow-up to #477 (which isolated/containerized the integration harness and corrected the test's skip guard so it skips cleanly instead of failing).

Why it currently can't run

• The auth-flow limiter hard-codes a no-op in build_mode=test (api/auth_flow_rate_limiter.go:74-78; TMI_BUILD_MODE is set from config by auth/service.go:109).
• The integration test server must run build_mode=test for the built-in tmi OAuth provider that every other workflow test depends on.
• Therefore the limiter is disabled wherever the integration suite can authenticate, and the test skips (guarded by framework.IsAuthFlowRateLimitingActive, which treats a present-but-zero X-RateLimit-Limit as "not enforcing").

What needs to happen

1. Product affordance to enable the auth-flow limiter independently of build_mode, so it can be exercised while the tmi provider is still available. Options to weigh:
   • A dedicated toggle (e.g. an env/config flag) that forces the auth-flow limiter on regardless of build mode; or
   • A dedicated non-test-mode server fixture for the rate-limit workflow tests.
2. Refresh the stale test expectations: TestAuthFlowRateLimiting_MultiScope asserts per-scope limits of 5 / 10 / 20, but the implementation now uses 100 across all scopes (api/auth_flow_rate_limiter.go checkRateLimitWithIPLimit). The test's multi-different-limits premise no longer reflects the code.
3. Wire it into the harness: scripts/run-integration-tests.py already supports TMI_TEST_ENABLE_RATE_LIMITING=true and a TMI_TEST_WORKFLOW_RUN filter; the new affordance should plug into that path so the test runs (and passes) when rate-limit coverage is requested, and continues to skip by default.

Acceptance Criteria

• The auth-flow limiter can be enabled for integration tests without disabling the tmi OAuth provider.
• TestAuthFlowRateLimiting_MultiScope actually runs (not skips) under that mode and verifies session, IP, and user scope 429s + X-RateLimit-Scope/Retry-After headers.
• Test expectations match the implemented limits (currently 100/scope) rather than the stale 5/10/20.
• The default make test-integration-pg run is unaffected (rate limiting stays off by default; the test still skips cleanly there).

Notes

• Limiter no-op gate: api/auth_flow_rate_limiter.go:74-78
• Build-mode env wiring: auth/service.go:109
• Skip guard: test/integration/framework/ratelimit.go (IsAuthFlowRateLimitingActive)
• Test: test/integration/workflows/auth_flow_rate_limit_test.go
• Unit coverage (already exists): api/auth_flow_rate_limiter_test.go

[ericfitz]

Resolved in 40c0e38 on branch dev/1.4.0.

• Added a test-only override (TMI_TEST_FORCE_AUTH_FLOW_RATE_LIMITING) so the auth-flow limiter can be enforced while the server still runs build_mode=test for the built-in tmi OAuth provider.
• run-integration-tests.py passes the override into the test server container when TMI_TEST_ENABLE_RATE_LIMITING=true.
• Rewrote TestAuthFlowRateLimiting_MultiScope to the implemented 100/scope limits, isolating session/IP/user scopes via X-Forwarded-For (the test server has no trusted proxies, so it honors XFF). Verifies each scope's 429 + X-RateLimit-Scope + Retry-After.

Verified: TMI_TEST_ENABLE_RATE_LIMITING=true run executes and passes; default run skips cleanly (0 passed, 0 failed, 1 skipped); full unit suite green.