POST /events/batch has no limit on how many events one call can submit

The entire point of the bounded IngestQueue is that memory is capped regardless of traffic — but that guarantee assumes individual requests stay reasonably sized. ingest_batch accepts a list of events with no upper bound on length, so a single POST /events/batch call can force the server to fully parse and validate an arbitrarily large JSON array into memory before the handler even runs, well before backpressure ever gets a chance to apply. Settings.max_batch_request_size already exists specifically to cap this, but nothing reads it.

ingest_batch accepts events_in: list[EventIn] with no check against Settings.max_batch_request_size (default 5000) anywhere in the handler.

1. pytest practice_tickets/tests/test_ticket_13_batch_size_cap.py -v — posts a 10-event batch against a configured max_batch_request_size=5 and confirms it is currently accepted with 200 instead of rejected.

FastAPI has to fully parse and validate a JSON array into a list[EventIn] before your handler code runs at all; a request with, say, 5 million events forces the server to materialize 5 million EventIn Pydantic objects in memory just to find out the request should be rejected — by which point the damage is already done. The cap needs to stop the request as early as possible.

Look at how ingest_batch currently starts (app/routers/events.py) and where settings.max_batch_request_size would need to be checked relative to len(events_in). You'll need access to Settings in this handler — app/dependencies.py::get_settings already exists and is used the same way elsewhere in this file. Think about whether checking length after FastAPI has already parsed the whole list into EventIn objects still achieves the goal, or whether a smaller list is needed to meaningfully cap peak memory.