feat(playground): rate-limit manual session creation #78

Summary

/playground now exposes a manual fallback path that creates a new playground session directly from the web app. That POST currently creates a new SQLite row with no abuse protection.

Why

The MCP-first landing flow is correct, but the manual session endpoint can still be spammed by repeated requests. We already have per-IP rate limiting patterns in the reviews flow, so playground session creation should have a similar guardrail.

Suggested direction

• add per-IP rate limiting for manual session creation
• keep MCP-driven create_playground behavior unchanged unless we explicitly want the same protection there
• reuse or extract the existing reviews rate-limit approach where it makes sense
• return a clear user-facing error when the limit is hit
• add tests covering the allowed window and the rejection case

Context

Follow-up from PR #77 review comment 4 so the concern is tracked without expanding that PR's scope.