New events keep getting accepted after shutdown has already begun

Shutdown currently sets a stop event and lets flush workers drain whatever's in the queue, then the process exits — but nothing stops a brand-new HTTP request from being accepted onto the queue at any point during that window, including after the flush workers have already finished draining and are about to exit. An event accepted at exactly that moment sits in the queue with nobody left to pull it out before the process terminates — a narrow but real data-loss window.

app.state.draining already exists and POST /events / POST /events/batch already check it and immediately return 503 when it's True — but nothing ever sets it to True. It stays False for the entire life of the process, including during the shutdown finally block.

1. pytest practice_tickets/tests/test_ticket_18_draining_flag.py -v — exits the app's lifespan context (shutdown fully completes) and checks app.state.draining, which is still False.

Right now, shutdown works like this: stop_event.set(), then flush workers switch into drain mode and empty out whatever's currently in the queue, then the process exits. But nothing stops a new HTTP request from calling queue.put() at any point during that window — this is exactly the kind of gap that "start refusing new work before you start winding down existing work" is supposed to close, and the ordering matters: gate first, drain second.

Look at the finally: block in app/main.py's lifespan function — specifically its very first line, and what would need to happen there relative to stop_event.set(). The check on the request-handling side (app/routers/events.py) is already correct and doesn't need to change.