Readiness-aware view exploitation: distinguish predicate-pruned empty MVs from unpopulated ones

[zhuqi-lucas]

Rationale for this change

A materialized view candidate whose scan yields an empty plan is ambiguous. Either the predicate genuinely pruned everything, in which case the empty candidate is the correct answer and dramatically cheaper than scanning the base table (a selective filter on a rarely-matching literal), or the MV simply has not been populated yet, in which case trusting the empty plan silently returns wrong results. A cost function today cannot tell these apart, so the safe policy is to penalize every empty candidate, which also throws away the legitimate predicate-pruned wins.

What changes are included in this PR?

• RewriteReadiness (Ready / NotReady / Unknown) and Materialized::rewrite_readiness() (default Unknown), letting table providers report lifecycle state. New module rewrite::readiness.
• CandidateMetadata (Base | Materialized { table_ref, readiness }) carried per branch via a RewriteContext attached to OneOf / OneOfExec, positionally aligned with branch order.
• Stable branch ordering (prerequisite for the alignment): OneOf::inputs() now returns branches in stored order. It previously re-sorted with LogicalPlan::partial_cmp on every call; since with_exprs_and_inputs rebuilds branches from inputs() output, any optimizer pass that mutates a branch's shape could move the base plan off branches[0], at which point OneOf::schema() exposes a candidate's schema instead of the query's. Candidates are now sorted by table reference at construction (the mv_plans HashMap iteration order was also nondeterministic across processes) and the base plan is pinned at branches[0].
• Two-gate NotReady filtering: dropped at logical rewrite time, and again at physical planning time after a refresh.
• Physical-time readiness refresh in plan_extension: by the time the physical planner runs, every candidate's scan() has executed, so providers whose readiness depends on scan-time side effects (e.g. lazy index loading on first scan) are re-consulted for the definitive value. Providers can additionally opt into ReadinessAnnotatedExec, a transparent wrapper carrying readiness captured atomically from the scan's own snapshot; the refresh prefers the annotation over re-sampling, which closes a TOCTOU race (scan sees an unpopulated source and plans empty, a concurrent load publishes the source, the refresh re-samples and wrongly trusts the stale empty plan). The wrapper is stripped before the OneOfExec is constructed so it never impedes later optimizer passes.
• CostFn signature change: cost functions now receive a CostContext (candidate plan iterator + RewriteContext) instead of a bare iterator, so they can implement readiness-aware policies such as "trust Ready empty candidates, keep penalizing Unknown empty ones".

Are these changes tested?

43 new unit tests: readiness types and annotation/strip round-trips, both filtering gates, the physical-time refresh (including the scan-transition and all-candidates-NotReady short-circuit cases), and branch-order/metadata alignment across with_exprs_and_inputs rebuilds.

Are there any user-facing changes?

• CostFn is a breaking signature change: existing cost functions change from Fn(Box<dyn Iterator<Item = &dyn ExecutionPlan>>) to Fn(CostContext), where CostContext::into_candidate_plans() returns the same iterator.
• Plan selection between exactly-tied candidates becomes deterministic (base first, then candidates by table reference).
• Materialized gains a provided method (rewrite_readiness), default-implemented, so existing implementations are unaffected.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.