Make live route writes cheaper so the prefix handler keeps up (closes #96)

The live route tables lose their random UUID key; the row id the
prefix-length sample draws is declared as the integer key. The prefix
tables are keyed by prefix and keep only first_seen; a batch inserts only
prefixes not stored yet. A route update sets only the columns that
change. Each kept index names the queries using it. Every write goes
through one connection kept for writing, with a 1 GiB page cache; reading
connections get 16 MiB, heap limits rise to 1.5 and 2 GiB (README
"Memory"). Batch writes go in key order. A benchmark run by hand writes
250,000 updates on 5 million routes faster than the feed's 10,000 a
second; a live run follows.

Model: opus-5-5

README.md

@@ -117,7 +117,7 @@ routewatch/
     - Signal handlers registered for graceful shutdown
 
 2. **Initialization** (`internal/routewatch/app.go`)
-    - Database created with SQLite schema (WAL mode, 3GB cache)
+    - Database created with SQLite schema (WAL mode, page caches as in "Memory")
     - Message handlers registered with the streamer
     - HTTP server started on configured port
 
@@ -170,8 +170,8 @@ routewatch/
 ```sql
 -- Core tables
 asns(id, number, handle, description, first_seen, last_seen)
-prefixes_v4(id, prefix, mask_length, first_seen, last_seen)
-prefixes_v6(id, prefix, mask_length, first_seen, last_seen)
+prefixes_v4(prefix, first_seen)
+prefixes_v6(prefix, first_seen)
 
 -- Live routing tables (one per IP version)
 live_routes_v4(id, prefix, mask_length, origin_asn, peer_ip, as_path,
@@ -215,8 +215,12 @@ data it tracks. The image sets ceilings that keep it inside a 5 GiB container.
 Budget:
 
 - Go heap: a 1.5 GiB soft limit (`GOMEMLIMIT=1536MiB`, set in the image).
-- SQLite: at most 640 MiB of page cache across the connection pool (64 MiB per
-  connection, 10 connections) and a 1.5 GiB hard heap limit for the C library.
+- SQLite: 1 GiB of page cache for the one connection every write uses, which
+  keeps the pages the route writes touch from one batch to the next, and 16 MiB
+  for each of the 9 reading connections, whose cache SQLite empties whenever
+  another connection has written: about 1.15 GiB in all. A 1.5 GiB soft heap
+  limit sits above the caches, so it does not shrink them, and a 2 GiB hard heap
+  limit caps the C library.
 - glibc allocator: the SQLite C library runs on glibc `malloc`, which frees
   page-cache chunks back to per-arena free lists rather than to the kernel, so
   process RSS tracks the high-water mark of those arenas, not SQLite's live
@@ -226,6 +230,9 @@ Budget:
   database writes are already serialized.
 - About 0.2 GiB for everything else in the runtime.
 
+The ceilings add up to 3.7 GiB: the Go heap's 1.5 GiB, SQLite's 2 GiB and the
+0.2 GiB for the rest.
+
 Run the container with a memory limit of 5 GiB and swap disabled:
 
 ```bash
@@ -244,8 +251,8 @@ What happens at each limit:
 
 - Go soft limit: as the heap approaches `GOMEMLIMIT`, the runtime runs garbage
   collection more aggressively rather than growing further.
-- SQLite: at a 1 GiB soft heap limit it recycles its page cache instead of
-  allocating more; at the 1.5 GiB hard heap limit a statement fails with an
+- SQLite: at the 1.5 GiB soft heap limit it recycles its page cache instead of
+  allocating more; at the 2 GiB hard heap limit a statement fails with an
   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.