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 lets the lock go after every 10,000 prefixes. The handler
runs it on a separate goroutine, one peer at a time. It holds back the
down peer's later messages until that PeerDown returns. Then it 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,16 @@ 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. It holds back the down peer's later
+  messages until that peer's `PeerDown` returns. Then it 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.
+  `PeerDown` lets the table's lock go after every 10,000 prefixes, so the IP
+  lookup and the pages no longer wait for the whole visit. 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