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 writes the table's changes first. A failed write
puts its changes and new peers back in the table, so the next write takes
them with each pair's content then. Stop writes the last changes, and
logs those left when its deadline passes.

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,11 @@ 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 failed
+  write is written again with the next one. 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 +259,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