Take every down peer out of the table in one walk (closes #225)

The prefix handler ran one PeerDown per peer, one after another, and
stopped taking messages at 20,000 held-back messages. Sessions going
down together queued up their walks, so a returning full-table peer
could reach that limit.

The table's PeersDown now takes several peers out of every prefix in
one walk. One walk runs at a time. The next one takes every peer whose
session went down meanwhile, so a message is held back for two walks at
most. Each walk takes about 2.6 seconds for each full-table peer it
takes out. The limit is now 150,000 messages, about 150 MiB: enough
when four full-table peers go down together. The status page shows how
many messages each handler holds back.

Model: opus-5-5

TODO.md

@@ -35,6 +35,16 @@ tested.
 
 # Completed Steps
 
+- 2026-11-02: when several peers' sessions go down at once, the prefix handler
+  goes on taking messages. The table's `PeersDown` takes several peers out of
+  every prefix in one walk over the table. One walk runs at a time. The next one
+  takes every peer whose session went down meanwhile. So a peer's messages are
+  held back for two walks at most. Each walk takes about 2.6 seconds for each
+  full-table peer it takes out. The handler holds back at most 150,000 messages,
+  about 150 MiB. The limit is enough when the sessions of four full-table peers
+  go down together. The status page shows how many messages the handler holds
+  back. Each peer used to have a walk of its own, and the handler stopped taking
+  messages at 20,000 held back (closes #225)
 - 2026-11-02: like a failed WHOIS lookup, a lookup skipped because its RIR is
   paused makes the fetcher wait longer before the next lookup. The longest wait
   is one minute. The status page does not count a skip as a failure. A skip used