A fully successful batch reports rejected_reason="queue_full"

BatchIngestResult.rejected_reason exists to tell a client why some of its events were rejected. A client (or an automated retry/alerting system) that checks rejected_reason to decide whether to back off would see "queue_full" on a batch where nothing was rejected at all — actively wrong information attached to a successful response. Anyone debugging "why does my monitoring say we're seeing queue_full errors when our own dashboards show 0 rejected events?" will lose real time chasing a field that's simply computed from the wrong variable.

BatchIngestResult.rejected_reason is supposed to tell a client why some of its events were rejected, but the final return BatchIngestResult(...) in ingest_batch derives it from the wrong local variable, so a fully successful batch can report a rejection reason that doesn't apply.

1. pytest practice_tickets/tests/test_ticket_09_rejected_reason.py -v — posts a small batch to a queue with plenty of room (nothing should ever be rejected) and checks the response body's rejected_reason field.

"queue_full" if accepted else None and "queue_full" if rejected else None are one identifier apart and both "look plausible" next to a function that has both an accepted and a rejected local variable in scope — exactly the kind of near-miss that autocomplete or a fast typing session produces, and that a reviewer skimming for "does this reference a real variable" won't catch, because it does.

Look at the final return BatchIngestResult(...) in app/routers/events.py::ingest_batch. rejected_reason is supposed to describe why events were rejected — which of the two local variables, accepted or rejected, actually answers "were any events rejected"?