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 the table's read lock.
After each batch of 10,000 prefixes, the walk 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. During a walk, its queue could fill, and the
streamer then dropped updates for it.

The walk now lets the lock go for as long as it held the lock for the
batch, as PeerDown does. A test applies another peer's 1,000
announcements while Overview walks a table with more prefixes than five
of the walk's 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. During a walk, its queue could
+  fill, and the streamer then dropped updates for it (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