POST /events/batch returns 503 even when most events were accepted

ingest_batch's own docstring (still accurate!) explains the intended contract: partial success returns 200 with a per-event accepted/rejected breakdown, and only a complete failure returns 503. The actual condition governing that decision now fires the 503 branch whenever any event in the batch was rejected — even if 999 out of 1000 were accepted. A client watching for 503 as its signal to back off will back off far more aggressively than the real queue state warrants, and a monitoring dashboard counting 503s as "total outage" moments will register one for every batch that merely brushed up against a momentarily-full queue.

ingest_batch's own docstring describes the intended contract: partial success returns 200 with an accepted/rejected breakdown, and only a complete failure returns 503. The actual guard governing that decision fires the 503 branch whenever any event in the batch was rejected, even if nearly all of them succeeded.

1. pytest practice_tickets/tests/test_ticket_08_batch_partial_success.py -v — uses a stalled fake DB backend and a queue sized to accept some but not all of a batch, then checks the response status.

and vs or in a two-term boolean guard is one of the easiest things to get backwards, especially when the intended English ("fail only if nothing got through") has to be translated into "accepted is zero AND rejected is nonzero" — it's tempting to instead write "if there's any sign of trouble at all," which is a different, broader condition that silently swallows every partially-successful response.

Read ingest_batch's own docstring in app/routers/events.py — it already states the intended contract precisely. Compare that stated contract against the actual if condition a few lines below it.