Keep taking messages while a peer's session goes down (closes #216)

The table's PeerDown visits every prefix under the write lock, which
takes over a second on a full table. The prefix handler called it
inline, so its queue filled and the streamer dropped updates.

PeerDown now holds the lock for 10,000 prefixes at a time, then lets
the lock go for as long again. The handler runs PeerDown on a separate
goroutine, one peer at a time. The handler holds back the down peer's
later messages until that PeerDown returns. Then the handler applies
them in order, one at a time, and takes new messages in between. It
holds back at most 20,000 messages. Stop waits for all of this before
its last flush.

Model: opus-5-5

TODO.md

@@ -35,6 +35,15 @@ tested.
 
 # Completed Steps
 
+- 2026-11-02: a peer's session going down no longer stops the prefix handler.
+  The handler runs the table's `PeerDown` on a separate goroutine, one peer at a
+  time, and goes on taking messages. `PeerDown` holds the table's lock for
+  10,000 prefixes at a time, then lets the lock go for as long again. The
+  handler holds back the down peer's later messages until that peer's `PeerDown`
+  returns. Then the handler applies them in order, one at a time, and takes new
+  messages in between. It holds back at most 20,000 messages. At that number,
+  `HandleMessage` waits until one of them is applied. When `Stop` runs past its
+  deadline, it logs how many held-back messages were not applied (closes #216)
 - 2026-11-02: the AS handler never waits for a database write. Its batch holds
   one entry per AS, with the earliest and the latest time of its updates. So the
   batch no longer grows with the feed's rate. It used to hold one entry for each