fix(promql): lower workloads with ingestion intervals

[milindsrivastava1997]

PromQL instant selectors need an explicit selection horizon that survives lowering and maintained-population compilation. This PR supplies it from source ingestion cadence.

Before this PR

Bare instant selectors lower directly to scans, losing their selection horizon; maintained current-series populations use a fixed expiry horizon.

After this PR

DataWorkload::data_ingestion_interval supplies a nonzero cadence. PromQL workload lowering accepts a PlanningWorkload and explicit planning timestamp, rejects unavailable cadence evidence, and wraps instant selectors in the declared time range. Explicit range selectors keep their query range. Maintained populations preserve and validate the same expiry horizon through Post-ASAP IR handling and executable-DAG compilation.

CLI tools, examples, and tests migrate to the workload lowering API. Freshness coverage includes future observations, expiry boundaries, expired evidence, and missing observation timestamps.

This PR targets main after #442 merged. #442 introduced only the query/data workload split; this PR adds ingestion-interval lowering and IR handling.

Validation

• The final file tree is identical to previously validated commit 7fbfaf2 (full workspace tests, formatting, and Clippy passed).
• Regression tests cover cadence freshness and maintained-population horizons.

[milindsrivastava1997]

@zzylol Pls check the entire PR description. Code is in progress.

[milindsrivastava1997]

@zzylol code is done

[zzylol]

I'm not sure why data ingestion interval is a requirement to lower for PromQL, it may be useful for dataworkload as input to planner in general.

Also, the data ingestion interval (sample scraping interval in prometheus), and the query window range are two concepts, not sure how they are related in this PR.

[milindsrivastava1997]

@zzylol See issue 408. To convert PromQL instant selector queries to pre ASAP IR, we need a scrape interval. For range selector queries too, the scrape interval helps guide the possible sliding window choices we can use for precomputation.

[zzylol]

Updated PR organization: #442 contains only the query/data workload split and targets main. #417 is stacked on #442 and contains ingestion-interval lowering, cadence freshness, and Post-ASAP IR handling. Merge #442 first, then retarget #417 to main. The two PRs are complementary.