ops(security): add edge rate limiting for /api/tiles and tune from real download traffic

Problem

GET /api/tiles is a Cloudflare Pages Function that proxies allowlisted tile providers for SMP downloads. It currently includes a best-effort in-memory per-IP limiter (5000 requests / 60s), but that counter is scoped to an individual runtime isolate and is not meaningful distributed abuse protection.

The application limiter is still useful as defense-in-depth. The missing layer is an edge/zone rate-limiting rule that runs before the Pages Function and is tuned from real legitimate SMP download traffic.

Scope

Use Cloudflare's edge/zone rate-limiting infrastructure appropriate for the current Pages deployment model.

Do not introduce KV or Durable Objects for rate-limit state unless edge rate limiting is demonstrated to be unable to satisfy the abuse-protection requirement.

Rollout

1. Measure legitimate /api/tiles request bursts from representative SMP downloads, including small and large areas/zoom ranges.
2. Define a rule scoped narrowly to the production host and GET /api/tiles.
3. Start in log/monitor mode where the available Cloudflare plan/tooling supports it, or otherwise use the closest non-blocking validation mechanism available.
4. Exercise representative legitimate downloads and inspect would-block/threshold behavior.
5. Tune the threshold/window from observed traffic rather than copying the current per-isolate 5000/60s value blindly.
6. Enable enforcement only after legitimate traffic has been checked for false positives.
7. Document 429/block behavior, operational visibility, and rollback.

Acceptance criteria

• Legitimate tile-request burst patterns are measured from representative real SMP download flows before choosing the enforced threshold
• The edge rule matches only the intended CoMapeo host/environment and GET /api/tiles
• Other /api/* endpoints are not rate-limited by this rule
• Initial rollout uses log/monitor/non-blocking validation where supported
• Both small and large legitimate SMP downloads are tested against the proposed threshold
• Threshold/window are tuned from observed traffic and documented
• Enforcement is enabled only after false-positive validation
• Client-visible 429/block behavior is documented
• Operational rollback/disable steps are documented
• The current application-level limiter is retained as defense-in-depth unless there is a documented reason it is clearly redundant
• Documentation states that Cloudflare edge rate limiting is practical distributed abuse mitigation, not exact globally serialized quota accounting
• KV/Durable Objects are not added unless a concrete requirement is shown that the edge facility cannot meet

Non-goals

• Exact globally serialized per-user quota accounting
• Replacing the existing hostname allowlist, SSRF controls, timeout, or response-size limits
• Adding distributed state infrastructure preemptively

Start with the GET /api/tiles Cloudflare Pages Function and the current application-level limiter, then review the edge rate-limiting options for the deployment model. Measure representative small and large SMP downloads before choosing a threshold. Done means the narrowly scoped rule is validated and enforced, with 429 behavior, visibility, rollback, tuning, and retained defense-in-depth documented.