Trace latency: add refresh-epoch result caches

Parent: #281

# Goal

Make DataFusion result caches safe to keep longer by keying them with storage freshness and the full query shape.

TTL increases are only safe after cache keys include enough information to prevent stale or cross-query reuse.

# Scope

- Add a freshness marker such as `refresh_epoch` to result-cache keys.
- Ensure cache keys include the full query shape for span, metric, summary, and GenAI result caches.
- Keep empty-result caching conservative. Empty results are dangerous when data may arrive shortly after the query.
- Add cache metrics for hit, miss, stale miss, insert, eviction, and skipped empty result where useful.
- Only then evaluate TTL increases. Do not hard-code broad 30-minute or 1-hour TTLs without benchmark and freshness evidence.

# High-level design

The cache key should answer two questions: “is this the same query?” and “is this the same storage snapshot?” If either answer is no, the cache must miss.

Using a monotonic refresh epoch is usually safer than trying to reason about many table-specific versions in every call path, as long as it is updated consistently when the visible snapshot changes.

# Acceptance criteria

- Result-cache keys include full query shape and storage freshness.
- Empty-result behavior is intentionally short-lived or skipped.
- TTL increases are gated by benchmark data and correctness tests.
- Tests prove that a new refresh epoch causes an identical query to miss the old cache entry.
- Metrics show cache hit rate before and after the change.