feat(datafusion): trace query planning and execution

[amunra]

Adds tracing spans around the three DataFusion entry points in lance-datafusion that sit between a caller's request and the operators that do the work: filter optimization, plan execution setup, and plan analysis.

What is missing

execute_plan, analyze_plan_with_context and Planner::optimize_expr open no span of their own. The time spent simplifying and coercing a filter expression, building the session context and constructing the execution stream is attributed to whatever span the caller happens to have open, and analyze_plan's re-parenting of operator spans through TracedExec hangs them off whatever span the caller has open rather than a query-specific one.

What this does

• Planner::optimize_expr is wrapped in a filter_optimize span at trace level.
• execute_plan is wrapped in an execute_plan span at debug level. execute_plan is synchronous and returns a stream, so the span covers session-context creation, coalescing of a multi-partition plan and plan.execute() (stream construction), and closes before the caller polls the stream. Spans opened by operators while the stream is polled are not children of it.
• analyze_plan_with_context is wrapped in a span named analyze_plan at debug level. This function is async, drives the stream to completion inside the call, and already wraps the plan in TracedExec::new(plan, Span::current()) so that AnalyzeExec's per-partition tasks report under the caller's span; the new span gives that parent a name, so the whole analysis, including the operators' own spans, sits under analyze_plan. The attribute sits on analyze_plan_with_context, which holds the body, rather than on the thin analyze_plan wrapper, so callers of either entry point are covered; the span is named after the public entry point.

All three spans use skip_all: the plan, the filter expression and the execution options are not recorded as span fields, so enabling the spans adds a fixed per-call cost and never formats a plan tree.

Why this design

#[instrument] attributes on the existing functions leave the signatures untouched and let the span levels be tuned independently: filter optimization is per-query and cheap, so it is trace; execution setup and analysis are the natural top-level units of a query trace, so they are debug. Instrumenting the stream returned by execute_plan (so that polling is covered too) is deliberately out of scope here and is a separate decision.

Testing

The spans have no observable behaviour to assert, so there are no new tests. cargo test -p lance-datafusion and cargo clippy --all --tests --benches -- -D warnings pass.

Compatibility

No API, format or dependency changes; lance-datafusion already depends on tracing.

---

Tracking: Ported from rerun-io#71.

[lance-gatekeeper]

✅ Gate recommendation: approve.

The prior coverage finding is fixed: this revision verifies all three span names and levels, plus analyze_plan parenting for both plan execution and stream polling. The instrumentation remains narrowly scoped to tracing with no API or format changes.