xorq stat snapshot cache has no eviction and caches the batch aggregate as one entry — klass reloads can't be surgical

[paddymul]

Problem

The xorq stat snapshot cache has no eviction, and its batch aggregate is a single cache entry. The only thing keeping the cache bounded today is tallyman wiping the whole entry directory on every klass reload (buckaroo-data/tallyman#177), which is unnecessary for correctness: snapshots are keyed on a content hash of each query (xorq_stat_pipeline.py:197), so klass changes never produce stale hits.

Removing that wipe exposes two gaps:

• Snapshots for removed or edited stats are orphaned and accumulate under cache_storage_path indefinitely.
• All batch stats go through one table.aggregate(agg_exprs) query (xorq_stat_pipeline.py:405), so adding or editing any one aggregate stat changes that query's key and re-runs every aggregate.

Impact

Without the wipe, disk use grows with every stat edit. With it, every hot-reload recomputes everything cold. Neither is what the summary-stat edit loop needs.

Suggested fix

1. Eviction: a size cap or oldest-first pass over the snapshot directory (by mtime, touched on hit), run at load time rather than on reload.
2. Optional, if the batch aggregate turns out to dominate on wide tables: cache the batch per stat function. On a run, look up each function's snapshot, aggregate only the missing ones in one query, write one snapshot per function, and merge. Costs more small files.

Context

Identified while reviewing the fix for #957. Tallyman side: buckaroo-data/tallyman#177.