feat: preserve filters over planned summaries

[zzylol]

Before this PR

PR #365 preserves SQL Project nodes while recursively materializing their aggregate children. A filter above a derived aggregate still becomes one opaque KeepPreAsap subtree, however. For example:

SELECT t.service, t.p
FROM (
  SELECT service, approx_percentile_cont(latency, 0.9) AS p
  FROM metrics WHERE service = 'api' GROUP BY service
) t
WHERE t.p > 100
ORDER BY t.p DESC
LIMIT 5

The canonical DAG contains Limit -> Sort -> Project -> Filter -> Project -> Aggregate, but the Filter hides the summary-bound aggregate from the final executable DAG.

After this PR

Filter is an explicit read-time ValueOperation that preserves its canonical predicate and output schema. Global selection materializes the Filter child independently, so the example retains the complete Project/Filter/Sort/Limit chain over SummaryEstimate -> SummaryAgg.

The two selection scopes remain separate: service = 'api' stays in the raw Scan that populates the summary, while t.p > 100 executes only after summary readout. If a child is unsupported, only that child remains an opaque fallback leaf and the supported Filter stays explicit.

The operation uses the existing shared post-ASAP value-operation and execution-data-state contracts. No predicate is reordered across an aggregate.

Verification

• Rebased onto main including feat: add MetricsQL canonical frontend #368
• cargo test --workspace --locked
• cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
• cargo test -p asap-integration-tests --test sql_to_post_asap (7 passed)
• MetricsQL external-consumer and vendored-baseline verification scripts
• cargo fmt --all -- --check
• git diff --check

Limitations

• Join, Dedup, SetOp, window functions, and other relational operators remain conservative KeepPreAsap fallbacks.
• Runtime consumers must implement ValueOperation::Filter before executing the newly explicit node.