Clamp limit on list endpoints

[MrAlders0n]

Problem. Every list handler parses limit and passes it straight to SQL with no maximum (handlers/packets.go:96-104, nodes.go:70-78, observers.go, channels.go, messages.go, routes.go, stats.go ×5, traces.go). ?limit=1000000 is accepted, so a scraper can pull a whole table in a handful of requests and per-request rate limiting never bounds egress. List endpoints also bypass the Redis reader (internal/cache/reader.go:381-448), so each such request lands on Postgres.

Ask.

• One parseLimit(r, def, max) helper in handlers/, used by every list handler. Suggested max 200 (traces already asks 200; the SPA otherwise never asks above 100).
• Over-max: clamp or 400, either is fine, but log it with the client IP. Asking for more than the UI ever does is a strong scraper signal.
• routes.go:55-59 silently ignores a parse error; make it 400 like the others.

Context. Part of the anti-scraping work (2026-09-02): edge access logs, header hygiene and block lists are live on both deployments; beacon-web dev already handles 429 + Retry-After.

[n30nex]

I would like to prepare a focused fix for this as the API stability part of the performance work. The proposed policy is to preserve each endpoint's default, reject malformed or nonpositive limits with 400, and clamp valid oversized limits to 200 before calling the reader. I will cover every current limit-bearing list/stats endpoint, including the routes and traces parsers that currently ignore malformed input, and regenerate Swagger.

I checked the current web dev client: its ordinary pages and 200-row trace request fit within this cap. Validation will include handler regression tests, required Go checks, and Pi 5 runtime smoke tests. This is AI-assisted work and will receive author review before submission.