Staging rate-limit validation

Use this check when task batching reports HTTP 429 or appears to affect sign-in. It distinguishes the three relevant controls without changing production settings or exposing credentials.

Expected policy

• PATCH /api/employee/tasks/bulk accepts at most 50 task IDs per request and has its own 30-request/15-minute user-or-IP budget. A limit response carries code: TASK_BULK_RATE_LIMIT.
• Ordinary authenticated API traffic is limited per user. A limit response carries code: API_RATE_LIMIT_AUTHENTICATED.
• Ordinary unauthenticated traffic is limited per IP. A limit response carries code: API_RATE_LIMIT_UNAUTHENTICATED.
• GET /api/csrf-token and POST /api/auth/login do not use either generic bucket. Failed login attempts remain protected by the dedicated IP/account limiter, whose limit response carries code: LOGIN_RATE_LIMIT.

Safe staging check

Use an approved synthetic staging user and synthetic tasks only. Keep cookies and credentials in a temporary local cookie jar or the browser; never paste them into logs, issue comments, screenshots, or shell history.

1. Select no more than 50 synthetic August tasks for one synthetic client and use the Tasks page bulk reassignment once.
2. In browser developer tools, record only the request path, HTTP status, RateLimit-*/Retry-After headers, and response code. Do not capture cookies, CSRF values, request bodies, or user data.
3. Confirm the bulk request returns 200 and reports succeeded + failed equal to the selected count.
4. In a separate private window, fetch the login page and confirm CSRF bootstrap and a valid synthetic login still succeed. This verifies generic API pressure cannot lock the login entry path.
5. If a 429 occurs, classify it by response code. Do not repeatedly retry; wait for Retry-After and record the class for diagnosis.

The automated regression test is npm test -- --run server/middleware/apiRateLimitPolicy.test.ts.