feat(chat): add session-based chat rate limiting (#224)

[Creative-Titilayo]

Overview

This PR adds session-based chat rate limiting to BackendAcademy/src/chat/ so a single session cannot flood chat rooms with messages. It introduces a sliding-window rate limiter keyed by session (senderId) that is scoped to the chat module and independent of the global IP-based ThrottlerGuard. When a session exceeds the limit, the API responds with 429 Too Many Requests and a retryAfter hint.

Related Issue

Closes #224
Closes #219
Closes #258

Changes

⚙️ Session-Based Rate Limiter

• [ADD] BackendAcademy/src/chat/chat-rate-limit.ts
• Added a ChatRateLimiter using a sliding-window algorithm keyed by session (senderId).
• Default policy: 10 messages per 10 seconds, configurable via ChatRateLimitConfig.
• check() prunes timestamps outside the window, blocks when the limit is hit, and returns a retryAfterSeconds hint.
• Exposed DEFAULT_CHAT_RATE_LIMIT and a reset() helper for testing.

🌐 Chat Service Integration

• [MODIFY] BackendAcademy/src/chat/chat.service.ts
• Added a private enforceRateLimit(senderId) that throws an HttpException with status 429 Too Many Requests (payload includes statusCode, message, and retryAfter).
• Wired the check into both createMessage and shareCodeSnippet so they share one per-session budget.

🧪 Tests

• [MODIFY] BackendAcademy/src/chat/chat.service.spec.ts
• Added limiter-level tests: allows up to the limit then blocks, isolates sessions, and resets after the window elapses.
• Added service-level tests: rejects with 429 once a session exceeds the limit, and confirms the limit is shared across createMessage and shareCodeSnippet.

Verification Results

npm run typecheck (tsc --noEmit)  ✅ passed
npm test -- src/chat              ✅ passed (6/6)
npm run build (nest build)        ✅ passed
npm run lint                      ⚠️ existing repo issue only (no ESLint config present on main)

Acceptance Criteria	Status
Chat-specific rate limiting added under src/chat/	✅
Limiting is session-based (keyed by senderId)	✅
Applies to createMessage	✅
Applies to shareCodeSnippet (shared budget)	✅
Returns 429 Too Many Requests with retryAfter when exceeded	✅
Independent of the global IP-based ThrottlerGuard	✅
Build passes successfully	✅
Chat service tests pass successfully	✅

Notes

Chat state is currently held in memory, so the limiter is per-instance and resets on restart — consistent with the rest of the chat module today. If chat moves to multiple instances, the limiter should be backed by Redis (a module already exists in the repo) for shared state.

🤖 Generated with Claude Code

[drips-wave]

@Creative-Titilayo 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