Let the lock go for as long as it was held during Overview's walk (closes #226)

The home page's cards are worked out once a minute by Overview, which
walks every prefix of the routing table under its read lock. After each
batch of 10,000 prefixes it let the lock go and took it back at once.
The prefix handler, waiting for the write lock, then got in only once
per batch. Its queue filled, and the streamer dropped updates for it.

The walk now lets the lock go for as long as it held it for the batch,
as PeerDown does. A test applies another peer's 1,000 announcements
while Overview walks a table of more than five batches.

Model: opus-5-5

TODO.md

@@ -35,6 +35,12 @@ tested.
 
 # Completed Steps
 
+- 2026-11-02: working out the home page's cards no longer stops the prefix
+  handler. The walk over the routing table holds the table's lock for 10,000
+  prefixes at a time, then lets the lock go for as long again, as `PeerDown`
+  does. It used to take the lock back at once. The prefix handler then applied
+  about one update per 10,000 prefixes walked. Its queue filled, and the
+  streamer dropped updates for it once a minute (closes #226)
 - 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