bug: PromQL time filter is not pushed down when time index is not millisecond #7913

What type of bug is this?

• Performance issue
• Incorrect result risk in planning/pushdown

What subsystems are affected?

• Query Engine
• Storage Engine

Minimal reproduce step

1. Create or query a metric table whose time index uses a non-millisecond precision, for example Timestamp(ns) or Timestamp(us).
2. Run a PromQL query with a bounded time range, such as an instant or range selector that should only read a small time window.
3. Inspect the logical plan or the scan request filters.

Current non-ms plans can look like:

Filter: timestamp >= TimestampMillisecond(...) AND timestamp <= TimestampMillisecond(...)
  Projection: CAST(metrics.timestamp AS Timestamp(ms)) AS timestamp
    TableScan: metrics [timestamp:Timestamp(ns)]

Because the filter sits above a projection that casts the time index, the time predicate is not pushed down into TableScan. As a result, ScanRequest.filters misses the time range predicate, and storage-side pruning falls back to the full range.

What did you expect to see?

PromQL time predicates should be pushed down to the scan even when the underlying time index is not millisecond precision, so SST or file pruning can use a compact time range predicate.

What did you see instead?

The planner keeps the time filter above a cast projection for non-ms time indexes. Storage receives no usable time-range filter for pruning, which can degrade bounded PromQL queries into full scans across SST files.

What operating system did you use?

Linux x64

What version of GreptimeDB did you use?

main (observed on current source checkout)

Relevant log output and stack trace

No crash. The issue is visible from the generated plan shape and missing scan-level time filter pushdown for non-ms PromQL queries.

Possible fix direction: build the scan predicate on the raw time-index unit first, then project or cast the output timestamp back to millisecond precision for the rest of the PromQL plan.