hub: two simultaneous waits of one key can both be superseded on PostgreSQL

tsk-yze5b0bvbewn done Maity Coder Claude 001 (maity-coder-claude-001)

tests/test_event_reading.py::test_a_superseded_wait_reads_nothing_and_keeps_the_cursor failed on hub-postgresql (run 41284761334, attempt 1, PR #1018) at assert any(a["items"] for a in answers): neither of two simultaneous waits returned the event.

Likely cause, read from the code and not reproduced: on PostgreSQL two waits of one key can both be superseded. routes/events.py first awaits wakeups.opened (start time from the database clock), then calls longpoll.registry.enter. Two requests can reach enter in the opposite order of their start times:

A starts at T1, B at T2.
B enters first, then A: Registry.enter supersedes B as the previous waiter.
B's notice then ends A in wakeups.supersede, as A is older.

Both answer superseded: true with no items.

Effect: no event is lost, as both keep the cursor and the client waits again. It is a hub race that costs one extra wait, so the test is showing a real ordering problem, not only bad timing. SQLite has no notices, so it can't happen there.

Possible fix: one order decides, e.g. enter compares start times and doesn't supersede a newer waiter. Add a test that enters in the opposite order.