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: RouteWatch pauses an RIR's or NIC.br's WHOIS server for an hour
   after the server refuses a query. A refused or reset connection is a refusal.
   So is an answer with an `%ERROR:201:` or `%ERROR:202:` line. Lookups at the