Telemetry ingest

POST /v1/ingest/batch -- the SDK's telemetry, and the only endpoint in the product that scales with the customer's traffic rather than the vendor's.

Three consequences, all visible in this handler:

• It rate-limits itself, per workspace, before it does any work. Report section 9.5: "a rate-limiting company being taken down by unbounded ingest is an avoidable embarrassment". The charge happens first, and in its own committed transaction, so that a workspace over its limit costs one upsert rather than a thousand-row insert and so that a batch that goes on to fail still pays -- including one that fails validation, which is why the body is parsed inside the handler and not by a pipe.
• It writes no audit row. Every control-plane mutation does, inside its own transaction (migration 0003), and that write takes a per-workspace advisory lock. Taking it here would serialise the busiest endpoint we have behind the vendor's own dashboard writes -- the 22.7 s stall the week 2 review reproduced. Telemetry is traffic, not a control-plane change, and the request log is its own record.
• Everything the payload claims is re-checked. The workspace comes from the authenticated principal; the project, tenant and key ids in the body are strings an SDK sent, and IngestService.assertOwnership is where they stop being taken on trust.

POST /v1/ingest/batch

Answers 202 on success.

Authentication.

• A krsk_ secret key only. A person's session is refused on this plane.

Body. Read unparsed; validation happens inside the handler, after the charge or the signature check the handler's description explains.