Shutdown drain can report "fully drained" while an event is still mid-flush

Anything that needs to know "has every accepted event either landed in Postgres or definitely not landed" — an external drain-detection script, a deployment tool waiting for graceful shutdown to finish before killing a container, a test asserting zero data loss — has to check two signals together: queue_depth == 0 and events_in_flight == 0. During the shutdown drain path specifically, items pulled off the queue are not counted as in-flight, so there's a real window where both signals read zero while an event is still actively being flushed to Postgres. Anything relying on that combined signal to mean "fully drained, safe to proceed" can act too early — exactly the kind of race that shows up as "we lost one or two events on every deploy" and is maddening to reproduce on demand.

Anything checking "has every accepted event either landed in Postgres or definitely not landed" has to combine queue_depth == 0 with events_in_flight == 0. During the shutdown drain path specifically, items pulled off the queue are not counted as in-flight, so there is a real window where both signals read zero while an event is still actively being flushed.

1. pytest practice_tickets/tests/test_ticket_15_shutdown_drain_race.py -v — sets stop_event, calls _collect_batch directly with items already queued, and checks events_in_flight immediately after the items are dequeued but before the (stalled) flush completes.

This is a logical race across await points, not a memory-level data race (Python's asyncio has no preemptive threading) — but it's just as real: two branches of the same function are supposed to maintain the same invariant, and one of the two code paths that can remove an item from the queue simply doesn't uphold it. This is exactly the class of bug that a "does the happy path work" test won't catch, because shutdown/drain is, by definition, not the happy path.

Compare the two branches inside the while loop in _collect_batch (app/flush.py) — the normal-operation branch (using asyncio.wait_for(queue.get(), ...)) and the drain branch (using queue.get_nowait()). Both remove an item from the queue. Which one updates stats, and which one doesn't?