Track DataFusion trace latency implementation

# Goal

Track the DataFusion/Delta trace latency work from baseline instrumentation through layout fixes, bounded reads, maintenance, warmup, result-cache correctness, and deferred advanced cache options.

The current performance problem is mostly read-path object-store cost: Delta metadata refreshes, partition/file discovery, Parquet footer reads, bloom/filter/index page reads, and row-group range requests. The work here keeps Delta Lake and DataFusion as the analytical storage layer, while tightening the parts around it that decide how many files we touch and how much cold object-store I/O each request pays.

This parent issue links the implementation work in order. Each child issue should be small enough to review independently, but the whole set should be tracked together because later changes depend on the measurement and correctness work from the early steps.

# Constraints

- Keep Delta Lake and DataFusion for analytical trace/event storage.
- Keep Postgres focused on transactional metadata, leases, lookup bounds, state, and coordination.
- Do not move broad span payload storage or analytical scans into Postgres.
- Do not add a PVC-backed cache. PVC is not available for this deployment.
- Do not add a Postgres `BYTEA` object-store metadata cache unless a future measurement-backed design explicitly proves the operational cost is worth it.
- Do not increase result-cache TTLs until cache keys include the full query shape and a storage freshness marker such as `refresh_epoch`.
- Treat latency targets as hypotheses until the benchmark harness proves them.
- `eval_scenarios` has not shipped yet, so its first Delta layout can be changed without a migration. It should ship partitioned by a created-date partition derived from `created_at`.

# Tracking

Implementation order:

- [ ] #282
- [ ] #283
- [ ] #284
- [ ] #285
- [ ] #286
- [ ] #287
- [ ] #288
- [ ] #289
- [ ] #290
- [ ] #291
- [ ] #292
- [ ] #293

Suggested dependency shape:

- #282 should land first. It gives the rest of the work measurement and regression gates.
- #283 should land before maintenance, warmup, and cache TTL work. It fixes layout and cache-key correctness.
- #285 depends on the storage-state work in #286 for the best fast path, but bounded lookup can start with a conservative fallback.
- #287 should wait for #282 and #283 so Compact/Z-ORDER work is measurable and writer properties are consistent.
- #288 should wait for #282 and should account for #287’s file-layout behavior.
- #290 should wait for #286 and #283 so result caches have storage freshness and correct key shape.
- #293 stays deferred unless benchmark evidence from earlier issues justifies reopening one of the advanced options.

# Done

- Baseline metrics and repeatable benchmarks exist before speculative tuning lands.
- Writer properties, cache-key correctness, vacuum safety, and table layout issues are fixed.
- Trace-id and dashboard reads have bounded fast paths where the access pattern allows it.
- Delta maintenance runs under coordinated leases and does not block user requests.
- Metadata warmup is bounded and PVC-free.
- Result caches are keyed by storage freshness before TTLs are increased.
- Deferred advanced cache designs stay deferred unless benchmarks justify them.