Start no prefix flush after the stop deadline (closes #188)

When a write ran past the stop deadline, a full batch's wake-up or a tick
could wait beside Stop's context. The flush goroutine's select picked one of
them at random, so about half the time it wrote that batch after the
deadline. That was the intermittent failure of
TestPrefixHandlerSkipsItsLastWriteAfterTheStopDeadline. The flush goroutine
now takes a waiting stop first. A new test hands over a full batch while a
write is held; it fails about half its runs on the old code.

TestPrefixHandlerSkipsItsLastWriteAfterTheStopDeadline and
TestPrefixHandlerStopLogsTheTableChangesLeftUnwritten also failed when the
flush timer fired between two of their steps. Both now give the handler a
timer interval longer than the test.

Model: opus-5-5

TODO.md

@@ -33,6 +33,9 @@ tested.
 
 # Completed Steps
 
+- 2026-10-27: once the stop deadline has passed, the prefix handler starts no
+  flush. A batch that filled while a write ran past the deadline could still be
+  written after it (closes #188)
 - 2026-10-27: the prefix handler applies each update to the routing table in
   memory, and writes the table's changes to the database every second. A write
   takes at most 20,000 changed pairs, and the rest follow in the next writes. A