Keep a peer-down until its route delete succeeds (closes #101)

When the delete of a peer's live routes after its session went down
failed, the down was dropped and the routes stayed. The prefix handler
now keeps such a peer, once, with the updates it sent after the down,
for the next flush, which retries the delete before it writes them; each
failure is logged. At most the last 25,000 of those updates are kept,
outside the batch, so they do not start a flush. The delete runs in
chunks of at most 10,000 routes per table, taken in prefix order
through the peer's key, each chunk in its own transaction, so the
database lock is released between chunks and a failure undoes at most
one chunk.

Model: opus-5-5

README.md

@@ -318,8 +318,14 @@ What happens at each limit:
   (`peerBatchMaxSize`, about 10 MiB) and 250,000 for the prefix handler
   (`prefixBatchMaxSize`, about 60 MiB). At that size the handler takes nothing
   more off its queue until the write ends, so the queue fills and the streamer
-  drops messages as above. With the batches being written, the three handlers'
-  batches take at most about 0.25 GiB of the Go heap's 1.5 GiB.
+  drops messages as above. When the delete of a peer's live routes after its
+  session went down fails, the prefix handler keeps the updates the peer sent
+  after the down for the next write, which retries the delete first; on top of
+  its 250,000 it keeps at most the last 25,000 of them (`prefixBatchSize`, about
+  6 MiB) and drops and logs the older ones, so while the delete keeps failing
+  the other peers' updates still come off the queue. With the batches being
+  written, the three handlers' batches take at most about 0.25 GiB of the Go
+  heap's 1.5 GiB.
 
 With `DEBUG=routewatch` the daemon logs a `System stats` line every 60 seconds
 with the goroutine count and Go memory figures.