fix(security): rate limit /api/errors/report to prevent log-flooding DoS

[3m1n3nc3]

Summary

/api/errors/report accepted error reports from client-side JS with no rate limiting, leaving it open to log-flooding DoS — an attacker could script thousands of requests/sec, flooding the logging system and exhausting in-memory log buffers.

This adds per-IP rate limiting to the endpoint.

Changes

• New REPORTING rate-limit tier (src/lib/ratelimit.ts) — 10 req/min per IP, a lower tier suited to unauthenticated, client-driven endpoints prone to flooding abuse.
• Applied rate limiting (src/app/api/errors/report/route.ts) — withRateLimit(request, 'REPORTING') runs at the top of the POST handler and short-circuits with HTTP 429 (including a Retry-After header) before any work is done. Accepted responses also carry X-RateLimit-* headers via addHeaders.
• Tests (src/app/api/errors/report/__tests__/route.test.ts) — cover over-limit → 429, presence of Retry-After, legitimate reports within the limit accepted, and per-IP isolation.

Acceptance criteria

• More than the configured limit within a window returns HTTP 429
• A Retry-After header is present in the 429 response
• Legitimate error reports within the limit are accepted and logged

Testing

• New route tests: 4 passed
• Existing ratelimit tests: 18 passed
• tsc --noEmit: no type errors in changed files

Closes #721

[drips-wave]

@3m1n3nc3 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[RUKAYAT-CODER]

Thank you for contributing to the project.