Delete expired negative cache rows in batches

CleanExpired deletes at most 1000 expired rows per statement and starts
no further statement once its context ends, so a request on the one
database connection waits behind one batch at most.

Model: opus-5-5

TODO.md

@@ -36,7 +36,9 @@ P2: security: per-origin rate limiting
   after that, so a client asking for a new missing path each time added rows
   that stayed for good. The eviction goroutine now calls `CleanExpired` at
   startup and on each periodic tick, every 5 minutes in pixad, so a row stays at
-  most about 10 minutes. It runs with the disk cache disabled
+  most about 10 minutes. `CleanExpired` deletes at most 1000 rows per statement,
+  so a request waits behind 1000 deletions at most, however many rows have
+  expired. The goroutine runs with the disk cache disabled
   (`cache_max_bytes: 0`) too, where it does nothing else, as the negative cache
   is used either way.
 - 2026-10-13 `fit=outside` no longer makes an output above 8192 on a side