Count what the cache holds in the default cache_max_bytes (closes #184)

The default cache_max_bytes was 75% of the space free at startup. The
cache's own files are not free space, so a fuller cache got a smaller
limit after a restart and eviction then deleted most of it. The default
is now 75% of the sum of the free space and what the cache already holds
by its own size accounting, at least 500 MiB. The cache works it out
when it opens, after the database is open, so the computation and its
tests moved from internal/config to internal/imgcache. The config only
records whether cache_max_bytes was set; newCacheConfig in the handlers
turns the disk cache off only for an explicit 0, and is tested for an
omitted, a zero and a positive value.

Model: opus-5-5

TODO.md

@@ -50,6 +50,14 @@ P2: security: referer blacklist
   share an identical line can end up one inside the other, which a rebase can
   do to an entry already on `next`. The Workflow above says to read the merged
   entries after every merge or rebase.
+- 2026-10-04 the default `cache_max_bytes` no longer shrinks as the cache fills
+  (closes #184): for an omitted key, the cache works out the limit when it
+  opens, after the database is open, as 75% of the sum of the free space on the
+  filesystem containing `<state_dir>/cache/` and what the cache already holds by
+  its own size accounting, at least 500 MiB, so a cache filled to its limit
+  keeps that limit across a restart. The computation and its tests moved from
+  `internal/config` to `internal/imgcache`; the config only records whether the
+  key was set.
 - 2026-10-04 `TestEvictionRunsOnPeriodicSchedule` no longer races the evictor
   (closes #183): it wrote each variant file and then inserted its accounting row
   by hand, and a reconciliation pass between the two adopted the file first, so