Write the routing table every second and read it at startup (part of #122)

The prefix handler applies each update to the routing table in memory as
it handles it, sorted into announcements and withdrawals as for the live
route tables. Each flush first writes at most 20,000 of the table's
changed pairs, with every new peer; the rest follow in the next flushes.
A failed write puts its changes and new peers back in the table. Stop
makes one last flush, and logs the changed pairs left.

Startup reads the table before the streamer connects, and logs its pairs,
peers and time. The per-peer counts are a slice, so the read takes about
a third less time. The health check's start period is 60 seconds, so a
full table's read fits before upaas looks.

Model: opus-5-5

TODO.md

@@ -33,6 +33,12 @@ tested.
 
 # Completed Steps
 
+- 2026-10-27: the prefix handler applies each update to the routing table in
+  memory, and writes the table's changes to the database every second. A write
+  takes at most 20,000 changed pairs, and the rest follow in the next writes. A
+  failed write is written again later. Startup reads the table before the
+  streamer connects. The pages still read the per-peer route tables (part of
+  #122)
 - 2026-10-27: the database keeps a copy of the whole routing table in a new
   `routes` table, one row per prefix and origin AS. The peers' numbers are in a
   new `route_peers` table. One function writes the pairs that changed in memory,
@@ -254,5 +260,5 @@ tested.
 # Future Steps
 
 - the rest of https://git.eeqj.de/sneak/routewatch/issues/122, one PR each: the
-  prefix handler writing to the routing table, the pages and the API reading
-  from it, then removing the per-peer route tables
+  pages and the API reading from the routing table, then removing the per-peer
+  route tables