The browser test waits for each page a click opens to load, and for
Alpine.js to start on it, before reading that page; before, a read
could find an element of the page being left.
The delivery tests' drain takes what is queued without a timer. The
dispatch paths queue before they return, and the 25 ms timer could be
due by the time select looked, which then chose at random between it
and a queued task.
The test phase keeps the tests' temporary directories, and with them
their SQLite databases, on a tmpfs: waiting for the disk at each commit
was about 40% of internal/handlers' run time on a busy host.
Model: opus-5-5
Restart recovery could find a just-written delivery pending, send it
and release it before the receiver's Notify queued the same delivery.
Notify's claim then succeeded on the released id, and the worker sent
it again because the new-task path never read the delivery's row.
Before sending a new task the worker now reads the delivery's status
by primary key and skips the task unless the row still says pending,
as the retry path already does for retrying. Nothing else can change
the row while the worker owns the delivery. A row left pending by a
failed bookkeeping write is still sent again.
loadRetryDelivery is renamed loadDelivery now that both paths use it.
Model: opus-5-5