serve: prune cached hashes to bound cache growth

[tinder-maxwellelliott]

What

The serve query service caches one hash entry per queried commit SHA under --cacheDir and never removed any, so a long-running server's cache grew without bound. This adds optional, off-by-default pruning that bounds the on-disk footprint.

New serve flags (all optional; unset = unlimited):

Flag	Meaning
--cacheMaxAge	Evict entries not read/written within a window, e.g. 7d, 36h, 90m.
--cacheMaxEntries	Cap the number of cached commit-SHA entries (LRU).
--cacheMaxSize	Cap total on-disk size, e.g. 10GB, 500MB, or a bare byte count.
--cachePruneInterval	How often the sweeper runs. Default 1h.

With no --cacheMax* flag set, the cache is never pruned (prior behavior).

How

• PrunableHashCacheStorage capability interface (extends the byte-oriented HashCacheStorage). LocalDiskHashCacheStorage implements it: LRU by last-use — get() bumps the file's mtime on a cache hit, so a base revision under active query is not expired out from under live traffic — and prune() evicts oldest-first by any combination of age / count / size. get() is also hardened against a file pruned out from under a concurrent read.
• CachePruner — a single daemon ScheduledExecutor that sweeps once at startup, then every --cachePruneInterval (fixed delay, so a slow sweep can't pile up). No-op when no limit is set; never throws, so a transient FS error can't kill the sweeper thread.
• DurationConverter / ByteSizeConverter — small reusable picocli converters for the human-friendly flag values.
• Wired into ServeCommand's startup/shutdown lifecycle. A backend that can't self-prune (a future S3 store, which would use a bucket lifecycle policy) is detected and the --cacheMax* flags are reported-and-ignored rather than silently pretended-to.

Notes for reviewers

• Pruning flags are deliberately not part of the config fingerprint — retention doesn't change hash content, and folding them in would needlessly partition the cache.
• The base HashCacheStorage interface stays byte-oriented so a remote backend still drops in unchanged (RFC RFC: Bazel Query Service #29 S3 direction).

Testing

• Unit tests: prune-by-age/count/size on a real filesystem, touch-on-hit LRU, non-.json files left alone, both converters, and CLI wiring/parsing (incl. the 1h default parsed through the converter).
• End-to-end: a test that drives the real scheduler against real on-disk storage and asserts files are deleted down to the limit.
• Real-bazel E2ETest#testServeEndToEnd (exercises the modified cache-hit path) passes. ktfmt/buildifier clean.
• Docs updated in tools/readme_template.md + regenerated README.md.