api: uniform 422 for a too-deeply-nested JSON request body

[rslayer]

Uniform 422 for a too-deeply-nested JSON request body

The 500 crash was already gone — but the responses were inconsistent by depth: ≤200 → normal 422, ~500–900 → 422 too_deeply_nested, ≥1000 → 400 "error parsing the body" (Starlette catching the parse-level RecursionError). This adds a small ASGI middleware that returns a uniform 422 too_deeply_nested for any body nested past MAX_JSON_NESTING_DEPTH (200), before the parser recurses.

• Scans only the first 64 KB of the raw body (early-exiting) — attack payloads are a few KB, legit large bodies are shallow. Cost: ~0.8 ms on the reject path (a full 6.9 MB scan would be ~280 ms — hence the bound).
• Registered inside CORS so the 422 carries CORS headers.
• Pathological padded bodies still fail safely downstream (clean 4xx, never 500) — the guard is for consistency, the crash is already prevented. ADR 0015.

Verified

• Uniform 422 across depths 200→20 000; normal requests still 200; guard ~0.8 ms.
• Full suite 19 → 16 failures — exactly the 3 deeply_nested tests flip to pass, zero new failures.

⚠️ Separate DoS found (flagged, not fixed here)

The analytics pipeline runs ~0.7 ms/point, so a single unauthenticated 100 000-point request (the MAX_PUBLIC_POINTS cap) ties up a worker for ~73 s. That's a real availability issue but orthogonal to deep-nesting — it needs its own cycle. Noted in ADR 0015 and memory.