[Bug]: [P3] The ingest body cap reads content-length, so a chunked request is buffered unbounded

Found by the Edge Case Hunter reviewing analytics stage 2. Pre-existing on the web route; recorded now because stage 2's module documentation newly names the body cap as one of the two defenses that actually bound abuse.

The cap reads content-length and skips the check when the header is absent or non-numeric (Number(null) is NaN, so Number.isFinite is false). A request with Transfer-Encoding: chunked and no content-length therefore reaches request.json() and is buffered in full, bounded only by Vercel's platform limit rather than by MAX_BODY_BYTES.

Probed: a roughly 120 KB body with no content-length reached the parser and returned 204, never touching the 413 branch. Also probed: new Request(url, {method:"POST", body}) sets no content-length at all, so the guard depends entirely on the platform supplying the header.

Acceptable in practice behind Vercel, which does send it. The problem is that the endpoint's documentation now presents the cap as a general property. Fix shape: either reject a missing or unparseable content-length on the desktop route, or qualify the sentence to say the cap depends on the platform setting the header.

Locate the web or desktop route where MAX_BODY_BYTES, the content-length check, request.json(), and the 413 branch are handled. Read the stage 2 module documentation sentence describing the body cap and inspect the existing request probes. Done means either missing or unparseable content-length is rejected consistently, or the documentation accurately qualifies the cap's platform dependency.