[Frontend] Add rate limiting to public and expensive frontend API routes

## Problem

ZKP generation, analytics export, observability, and webhook routes need explicit abuse controls.

## Relevant code

`src/pages/api`

## Proposed scope

Define per-route budgets, trusted proxy handling, Retry-After, privacy-safe metrics, and bypass tests.

## Acceptance criteria

- [ ] The reported behavior is reproduced or characterized with a focused automated test before the fix.
- [ ] The implementation satisfies the proposed scope without weakening TypeScript, lint, authorization, privacy, or error handling.
- [ ] Success, empty/loading where applicable, failure, and boundary cases are covered.
- [ ] Existing related tests pass and new regression coverage is included.
- [ ] User-facing behavior remains accessible by keyboard and at mobile viewport sizes where UI is affected.
- [ ] Documentation is updated when the change alters configuration, contracts, security assumptions, or contributor workflow.

## Contributor notes

Base the work on the latest `main` branch. Keep unrelated refactors out of the pull request and include screenshots or recordings for visible changes. Never use real pet, medical, contact, wallet, or credential data in fixtures.

Begin by inventorying the routes under src/pages/api and reading their existing authorization and error-handling paths. Define per-route budgets, trusted-proxy behavior, Retry-After responses, privacy-safe metrics, and bypass tests; done means focused regression coverage and related tests pass without weakening the listed TypeScript, lint, authorization, privacy, or error-handling requirements.

Written by the indexing model from the issue text.