Redis-backed rate limiting on public API endpoints

[Cbiux]

Summary

Add Redis-backed rate limiting on public API endpoints to protect against abuse — extend the in-memory event cap (#7) with IP and API-key based limits at the edge.

---

Background

Issue #7 caps score-impacting events per wallet per month. There is no protection against:

• Challenge endpoint spam (POST /api/auth/challenge)
• Brute-force signature attempts
• Platform API key abuse on /api/events/report

Vercel serverless makes in-memory rate limits ineffective across instances.

---

Proposed implementation

Provider: Upstash Redis (Vercel Marketplace integration)

Middleware: Server/src/middleware/rate-limit.middleware.ts

Route	Limit
POST /api/auth/challenge	10/min per IP
POST /api/auth/*/signed	5/min per IP
POST /api/events/report	100/min per API key
GET /api/user/*/score	60/min per lender key

Response: HTTP 429 with Retry-After header

Env: UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN

---

Acceptance criteria

• Rate limit middleware applied to listed routes
• 429 responses include readable error JSON
• Graceful fallback if Redis unavailable (log + allow with warning)
• Unit tests with mocked Redis client
• Document setup in README and .env.example
• No impact on /health endpoints

---

Related

• Rate limiting: cap events that count toward score per wallet per month #7 monthly event cap (different layer)
• Provision production MySQL and configure DATABASE_URL on Vercel #15 production env vars

---

Out of scope

• Vercel WAF rules (complementary)
• Per-wallet global rate limits

[snkk2x-collab]

/attempt #62

[Cbiux]

Resuelto en d259dc0: rate limits en auth/events/lender score con Upstash Redis + fallback in-memory y 429 Retry-After.