Feature/org rate limiting

[Devadakene]

Closes #241

Summary

This PR implements organization-based rate limiting to prevent one operator's heavy usage or DDoS from locking out other operators sharing the same office IP address.

When a request is authenticated with an API key, the rate limiter uses the associated organization ID (org:<orgId>) as the rate-limiting key. If no organization ID is present (e.g. unauthenticated requests), the rate limiter falls back to keying by the caller's IP address.

Key Changes

• Modified ApiKeyGuard to expose the organization ID on the request object as (request as any).org.
• Modified AdaptiveRateLimitGuard to use the organization key identifier org:<orgId> if present.
• Modified the createRateLimiter Express middleware to check for request.org (and resolve it from the database if x-api-key is supplied), falling back to the client's IP.
• Added comprehensive documentation inside docs/security/rate-limits.md.

Testing

E2E tests were added to app/backend/test/security.e2e-spec.ts matching the acceptance criteria:

1. Simulates 200 requests under org A and 200 under org B in parallel — verifying neither trips a 429 status code.
2. Simulates 51 requests under org A — verifying that the 51st request trips a 429 status code when the limit is set to 50.

Commands Run

# Set up database mapping path in Jest config and run the security suite
npm run test -- test/security.e2e-spec.ts --runInBand

Screenshots

N/A (Backend / API changes only)

Checklist

• Tests added or updated for new/changed behavior
• Existing tests pass
• No secrets, keys, or seed phrases committed
• Follows the coding conventions in the relevant service README
• PR is focused on a single concern