[#219] Add rate limiting to view count API

[realproject7]

Summary

• In-memory rate limiter on POST /api/views: max 10 requests per IP per storyline per hour
• Returns 429 Too Many Requests with Retry-After: 3600 header on excess
• Periodic pruning of expired entries to prevent memory leak
• IP extracted from x-forwarded-for header (standard for proxied deployments)

Test plan

• Normal view tracking still works (< 10 per hour)
• 11th request for same IP + storyline returns 429
• After 1 hour, rate limit resets
• Different storylines have independent limits

Fixes #219

🤖 Generated with Claude Code

[project7-interns]

T2b: APPROVE

Clean in-memory rate limiter:

• Key: ip:storylineId — correctly scoped per IP per storyline
• 10 req/hr window with periodic pruning to prevent memory leak
• Rate limit check before any DB calls — protects Supabase
• 429 with Retry-After header
• IP from x-forwarded-for (always present on Vercel)

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The rate limiter is keyed too broadly for how view tracking currently works. On story pages we already emit one POST for the storyline plus one POST per rendered plot, so limiting only by IP + storylineId blocks legitimate plot-tracking traffic on longer stories.

Findings

• [high] Story pages with many plots will hit the limit on first load
  • File: src/app/api/views/route.ts:13
  • File: src/app/api/views/route.ts:14
  • Suggestion: include plotIndex in the rate-limit key, or otherwise scope the limit to the actual page being viewed rather than the whole storyline. Right now the key is ${ip}:${storylineId}, but ViewTracker posts once for the storyline and once per PlotEntry, so a story with 10+ plots will start returning 429s to legitimate first-page loads even without abuse.

Decision

Requesting changes because the current limiter breaks the plot-level tracking introduced in #209 and violates the issue requirement that legitimate users remain unaffected.

[project7-interns]

Verdict: APPROVE

Summary

The follow-up change fixes the limiter scope by including plotIndex in the rate-limit key, so storyline-level and per-plot tracking no longer contend for the same hourly bucket. The updated head now preserves legitimate first-load behavior while still rejecting excessive repeated POSTs.

Findings

• None.

Decision

Approving because the previously blocking interaction with plot-level tracking is resolved, and GitHub lint-and-typecheck passes on the updated head.