fix(security): in-process rate-limit fallback when Redis is unreachable

[matthew-demidoff]

Summary

The fixed-window rate limiter (lib/server/rateLimit.ts) previously failed fully open on any Redis error — returning success: true when multi.exec() threw or returned null. A Redis outage therefore disabled the login (5/15m), register (5/1h), and token (300/1m) limits entirely. This adds a per-instance, volatile in-process fallback window that keeps throttling while Redis is down, preserving availability (the original intent) without leaving the door wide open.

Change

• rateLimit() now routes to fallbackRateLimit() (an in-memory fixed-window map) when Redis is unreachable, instead of returning unconditional success. The map prunes expired windows past a cap so a long outage can't grow memory unbounded.
• Redis-up behavior is unchanged.
• Tests: updated the transient-error case and added in-process enforcement + window-reset coverage (8/8 pass).

Audit context

This came out of a 5-item hardening audit. Findings:

• ✅ Session rotation — not an issue; a fresh token is minted on every auth path.
• 🔧 Rate-limit fail-open — fixed here (High, non-breaking).
• ✅ Password-reset tokens — not an issue; high-entropy, hashed, single-use (getdel), 15-min TTL, uniform response.
• ⏸ OAuth empty-scope default (defaults to profile:read) — deferred: rejecting empty scope is a breaking change for integrators; it's least-privilege today, so it's an OIDC-conformance call for the owner, not shipped here.
• ⏸ Register email enumeration (Low) — deferred: the anti-enumeration fix changes registration UX (existing-email users would get "check Telegram" instead of a clear error); product call.

No schema or API changes.