JobRegistry.notify() reintroduces a missed-wakeup race

The entire signature claim of this project -- long-polling costs far fewer requests than naive 1-second polling -- depends on one guarantee: a status change that happens while a GET /jobs/{id}?wait= call is parked wakes it up promptly, not after the full wait window. This bug reintroduces exactly the race the registry's own docstring describes and claims to avoid: a change that lands in the narrow gap between a caller reading "what should I wait on" and that caller actually starting to wait can be silently missed, forcing that request to sit out its full timeout instead of returning promptly. A caller experiencing this wouldn't see an error -- just occasional, unexplained slowness on an otherwise-fast long-poll, the kind of intermittent latency that's brutal to track down.

This reuses the same asyncio.Event object across every call to notify(), immediately clearing it right after setting it -- the class's own docstring explains exactly why replacing the Event object instead avoids a missed wakeup.

1. pytest practice_tickets/tests/test_ticket_14_registry_missed_wakeup_race.py -v
2. Or manually: handle = registry.create("job-x"), capture event = handle.event, call registry.notify("job-x"), then await asyncio.wait_for(event.wait(), timeout=0.5).
3. Observe: the wait times out instead of resolving immediately, even though the notify happened before the wait started.

This is a real concurrency bug, not a logic error you can spot by tracing through the code once -- it only manifests for a specific interleaving (a notify landing between "read the current Event" and "start waiting on it"), which real asyncio scheduling in a fast, low-contention test environment essentially never reproduces on its own. That's exactly why none of the existing black-box HTTP tests in this project catch it. A race that "isn't covered by any test" isn't the same claim as "doesn't exist."

Compare what happens to an asyncio.Event object across two calls to notify() under the current code (same object, .set() then .clear() on it) versus what the docstring says should happen (a new Event object each time, with .set() called on the old one). Think through why a waiter holding a reference to the old object still needs to see it resolve correctly even after has already moved on to a new one.