Read every route from the routing table in memory (part of #122)

The IP lookups, the AS and prefix pages and their API answers, the prefix-length pages and the stats read routes only from the routing table the prefix handler keeps. fx reads the table at startup and gives it to both. AS names, WHOIS details and first-seen times still come from the database.

The IP lookup names the origin AS most peers carry, with the time of the newest kept route. The prefix answers list peers whose routes are not kept without a path or time. The stats gain origins_without_kept_route. They no longer read route times from the per-peer tables, so the two helpers that did are gone.

Model: opus-5-5

README.md

@@ -16,12 +16,12 @@ to now or which routes a prefix has. RouteWatch applies the feed's updates to a
 routing table that it keeps in memory, with a copy in its own SQLite database.
 It answers IP-to-AS lookups and prefix pages from that table.
 
-The feed sends no table when a client connects, so the routing table holds only
-the routes the feed has announced since RouteWatch first started: an IP-to-AS
-lookup finds nothing for an address whose routes have not been announced since
-then. The routing table also misses the updates RouteWatch drops when it falls
-behind under load and those sent while it is stopped, so a lookup or a prefix
-page can show a route the feed has withdrawn.
+The feed sends no table when a client connects. So the routing table holds only
+the routes announced since RouteWatch first started. An IP-to-AS lookup finds
+nothing for an address whose routes have not been announced since then. The
+routing table also misses updates RouteWatch drops when it falls behind, and
+updates sent while it is stopped. So a lookup or a prefix page can show a route
+the feed has withdrawn.
 
 ## Features