Fix the origin-changes review findings

Hold the 100,000-row cap after a failed write's rows are put back, dropping and counting the oldest rows past it. Stop counts the unwritten origin changes. The prefix handler's per-write origin change limit is a field, so a test checks that one write leaves the rest. The server and README now say where origin changes come from. README, TODO and schema say 72 hours or 500 rows, whichever keeps more. The prefix page and TODO list the origin change columns and say what the peer count counts. The page takes its 5,000-row note from the constant.

Model: deepseek-v4-pro

README.md

@@ -143,10 +143,13 @@ and origin AS can have two kept routes, one or none.
   its origin ASes and every peer that carries it. Only the kept routes show an
   AS path, a next hop and a time. The next hop is the router the peer sends the
   prefix's traffic to. RouteWatch records the peer itself as the next hop. The
-  page also lists the prefix's origin changes, newest first: each time an origin
-  AS gained its first peer or lost its last, with the time, announced or
-  withdrawn, the origin AS and the peer count. It shows at most the newest
-  5,000.
+  page also lists the prefix's origin changes, newest first. It shows at most
+  the newest 5,000. The peer count counts the peers of every origin AS that
+  carries the prefix. Each row shows:
+    - the time
+    - announced or withdrawn
+    - the origin AS
+    - the peer count
 - `/prefixlength/{length}`: up to 500 IPv4 prefixes with that mask length,
   picked at random. Each shows its origin AS and the age of its newest kept
   route. When peers give a prefix different origin ASes, the page shows the one
@@ -625,8 +628,9 @@ The parts:
   messages. It gives each message to the handlers that want it, through one
   queue per handler.
 - The prefix handler keeps the routing table in memory current. Every second it
-  writes the table's changes to the `routes` table of the database. It also
-  stores each new prefix with the time it was first seen.
+  writes the table's changes to the `routes` table and the table's origin
+  changes to the `origin_changes` table of the database. It also stores each new
+  prefix with the time it was first seen.
 - The AS handler records every AS seen in an AS path in the `asns` table, with
   the times it was first and last seen.
 - The peer handler records every peer in the `bgp_peers` table.
@@ -643,11 +647,14 @@ The parts:
 - The database maintainer checkpoints the database every 5 seconds: it folds the
   write-ahead log, where SQLite first writes changes, into the database file. It
   reclaims free space every 10 minutes. Every hour it refreshes the statistics
-  SQLite uses to plan its queries, and prunes the origin changes table.
+  SQLite uses to plan its queries, and prunes the `origin_changes` table. A
+  prune keeps each prefix's rows from the last 72 hours, or its newest 500,
+  whichever keeps more.
 - The HTTP server serves the pages and the API. Every route it shows comes from
-  the routing table in memory. WHOIS details and first-seen times come from the
-  database. AS names come from the database or from the AS list built into
-  RouteWatch. The AS name search reads the AS list built into RouteWatch.
+  the routing table in memory. WHOIS details, first-seen times and origin
+  changes come from the database. AS names come from the database or from the AS
+  list built into RouteWatch. The AS name search reads the AS list built into
+  RouteWatch.
 
 ### The routing table
 
@@ -758,6 +765,8 @@ What a stop can lose:
   changed pairs. A full-table peer is a peer that carries the whole routing
   table. Its session going down changes about a million pairs, which take about
   a minute to write. A stop in that minute leaves the rest unwritten.
+- The same last write takes at most 20,000 of the routing table's origin
+  changes. Origin changes past them are lost.
 - A withdrawal, or a session going down, that is lost this way leaves its routes
   in the `routes` table. The next start reads them back. They stay until the
   peer sends another update for the prefix, or its session goes down again.