Trace latency: bound trace-id lookups by time

[thorrester]

Parent: #281

Goal

Make trace-id lookups avoid broad object-store scans by bounding the query to the smallest credible time window.

Trace-id lookup is an important user path and should not pay for scanning unrelated partitions when the system has enough metadata to infer where the trace can exist.

Scope

• Add or use a bounded lookup path for trace-id requests.
• Prefer recent time windows and known trace bounds before falling back to broader scans.
• Keep correctness: if a trace exists outside the fast-path window and no bound is available, the system must still be able to find it through the fallback path.
• Capture metrics for fast-path hits, fallback hits, misses, and lookup latency.

High-level design

The fast path should turn “find this trace somewhere in the lake” into “find this trace in a narrow set of partitions.” That reduces Delta file candidates, footer reads, bloom checks, and row-group reads.

Do not rely on bloom filters alone as the bounding mechanism. Bloom filters help after the candidate files are known; they do not replace a bounded time or partition search.

Acceptance criteria

• Trace-id queries use a bounded lookup when enough information is available.
• Fallback behavior preserves correctness for older or unknown traces.
• Metrics distinguish fast-path, fallback, and miss behavior.
• Benchmarks show object-store request counts for trace-id lookup before and after this change.