refactor: slowly phase out QueryPatternType and QueryType enums

[milindsrivastava1997]

• refactor: start_timestamp logic for OnlySpatial
• updated start/end timestamp validation logic
• removed special build_spatiotemporal_context function

[milindsrivastava1997]

QueryType::Spatial phase-out

As of the latest commits on this branch, query_info_to_pattern no longer constructs QueryType::Spatial. It's replaced by the same two buckets every other query duration already used:

• SpatioTemporal — GROUP BY doesn't cover all metadata columns (partial label coverage)
• TemporalGeneric / TemporalQuantile — GROUP BY covers all metadata columns (full coverage), split by whether the aggregation is QUANTILE

Previously, a query spanning exactly one scrape interval was forced into Spatial regardless of its GROUP BY, while longer-duration queries went through a label-coverage check to decide between TemporalGeneric/TemporalQuantile/SpatioTemporal. That asymmetry is gone now — Spatial was never a real structural distinction, just Temporal with range == scrape_interval, so every query is classified the same way regardless of duration. Concretely: a 1-interval query with a full GROUP BY now lands in TemporalGeneric/TemporalQuantile (previously Spatial), and a 1-interval query with a partial GROUP BY now lands in SpatioTemporal (previously also Spatial, which silently hid the partial-label case).

The Spatial variant itself stays defined (dead code) until a later commit on this branch deletes it, once sql.rs's dispatch is migrated off matching on it directly.

[milindsrivastava1997]

`QueryPatternType` phase-out, step 1: `get_statistics_to_compute`

Continuing the phase-out (see the earlier comment on `QueryType::Spatial`) — this time on the PromQL side's `QueryPatternType` enum (`promql_utilities`).

`get_statistics_to_compute` used to take `pattern_type: QueryPatternType` purely to decide which token to read:

```rust
match pattern_type {
OnlyTemporal | OneTemporalOneSpatial => read the function token (rate/increase/*_over_time),
OnlySpatial => read the aggregation token (sum/avg/...),
}
```

Replaced with direct token inspection, no enum needed:

```rust
match_result.get_function_name()...or_else(|| match_result.get_aggregation_op()...)
```

i.e. try the function token first (temporal wins when both a function and a spatial aggregation are present — same precedence as before for the "one temporal one spatial" shape), fall back to the aggregation token (the bare-aggregation "spatial" shape, e.g. `sum(metric)`). Behavior is identical; the enum branch and the token-presence check were doing the same thing, since a query can only reach one branch or the other depending on which tokens actually matched in the first place.

`StatisticExtractionError::MissingStatistic` correspondingly drops its `pattern_type` field (was only used for the error message) — it's now a unit variant.