Add rate limiting to authentication and account endpoints

## Context
Cornflow currently has no rate limiting on any endpoint. The login (`/login/`), sign-up, token, and password-recovery endpoints are therefore brute-forceable and abusable:
- credential stuffing / password brute force against `/login/`;
- enumeration and mass requests against account endpoints.

This is a feature rather than a one-line fix, so it is tracked separately from the password-policy and login-timing hardening already in progress.

## Proposed solution
1. Add a dependency such as **flask-limiter**.
2. Apply conservative default limits to sensitive endpoints — e.g. login: ~5–10/min per IP (and ideally per username); sign-up and password-recovery: a few per hour per IP.
3. Make limits configurable via env vars (e.g. `RATELIMIT_LOGIN`, `RATELIMIT_DEFAULT`).
4. **Storage backend:** in-memory storage only rate-limits per gunicorn worker and resets on restart. For real enforcement a shared backend (Redis) is required. Add a `RATELIMIT_STORAGE_URI` setting; document that production should point it at Redis, with in-memory as a dev-only fallback.
5. Return `429 Too Many Requests` with a `Retry-After` header.
6. Add tests covering limit enforcement and reset.

## Open decisions
- Whether Redis is acceptable as a new infra dependency for production deployments, or whether an existing store should be reused.
- Per-IP vs per-account keying for login (consider both, to resist distributed attacks and targeted lockout).

## Related
- Password policy hardening: PR #731
- Login timing hardening: PR #737
- Password-recovery redesign: #733

Start by locating the login, sign-up, token, and password-recovery endpoints and the existing deployment configuration. Resolve the open decision about Redis versus an existing store, then define configurable limits, 429 responses with Retry-After, and tests covering enforcement and reset.

Written by the indexing model from the issue text.