Remove a peer's live routes when its session goes down (closes #56)

RIS sends no withdrawals for the routes of a peer whose BGP session goes
down, so routewatch kept them.

The streamer now hands STATE messages to the prefix handler. They are never
dropped for backpressure: one that finds the queue full is held and queued
first once there is room, and the handler's other messages are dropped
meanwhile, so none overtakes it. Nothing waits. On a down, the prefix
handler drops the peer's pending updates and its next flush deletes all the
peer's live routes before the batch's other writes, keeping the in-memory
counts exact. The live route tables are unique on peer and prefix, which
also finds a peer's routes.

Model: opus-5-5

README.md

@@ -128,7 +128,10 @@ routewatch/
 4. **Handler Details**
    - **ASHandler**: Tracks all ASNs seen in AS paths
    - **PeerHandler**: Records BGP peer information
-   - **PrefixHandler**: Maintains live routing table (upserts on announcement, deletes on withdrawal)
+   - **PrefixHandler**: Maintains live routing table (upserts on announcement, deletes on withdrawal,
+     deletes all of a peer's routes when its BGP session goes down). Routes are kept per peer IP, so
+     when one peer IP has sessions on two collectors, a session going down on one also removes the
+     routes the other still carries, until they are announced again.
    - **PeeringHandler**: Extracts AS peering relationships from AS paths
 
 5. **HTTP Request Flow**
@@ -232,7 +235,9 @@ What happens at each limit:
   out-of-memory error, and the handler logs it and drops that batch. The process
   keeps running.
 - Handler queues: each of the four handler queues holds at most 20,000 messages.
-  When a queue fills, the streamer drops messages instead of blocking.
+  When a queue fills, the streamer drops messages instead of blocking, except a
+  `STATE` message, which it holds, in feed order, until there is room: a few
+  hundred bytes each, about ten a second.
 - Handler batches: while the AS, peer or prefix handler writes a batch to the
   database, the updates that arrive collect in its next batch, which stops at
   ten times the batch size: 300,000 updates for the AS handler