feat(api): add per-actor rate limit on POST /events/submit (and future /forms, /announcements submit)

Summary

POST /events/submit is auth-gated but unbounded — a single member could enqueue arbitrary draft events into the staff review queue. Same concern will apply to future member-facing submission endpoints in Plans 4 and 5.

Requirements

• Decide a sensible cap (e.g., 10 submissions per actor per 24h)
• Implement per-actor rate limit middleware that applies to POST /events/submit
• Surface rate-limit-exceeded as 429 Too Many Requests with a Retry-After header
• Add unit test covering the cap
• Make the middleware composable so future submission endpoints (Plans 4 + 5) can opt in

Context

Flagged in the Plan 2 review. Rate limiting is best done at the Worker layer (e.g., Cloudflare Workers KV or Durable Object). Plan 4 (forms) and Plan 5 (announcements/broadcast) will benefit from the same primitive.

Implementation Notes

Options:

• Cloudflare Workers Rate Limiting API (built-in, easy)
• KV-backed counter with TTL (cheap, works on the existing stack)
• Postgres-backed counter (consistent but adds DB hops to every submit)

Workers Rate Limiting API is the YAGNI default unless we need cross-region consistency.

Start at the authenticated POST /events/submit handler and review how the project runs requests at the Worker layer. Compare the listed Workers Rate Limiting API, KV-backed counter, and Postgres-backed counter options, then identify the existing unit-test setup. Done means a composable per-actor limit, 429 responses with Retry-After, and a test covering the cap.