fix(esql): check per-shard DateFieldType for DocValuesSkipper

[salvatore-campagna]

Summary

SearchContextStats.min()/max() derived hasDocValuesSkipper once from the first shard's DateFieldType and applied it globally to all shards via doWithContexts. In mixed environments (TSDB shards using DocValuesSkipper + standard shards using PointValues), the wrong API gets called on some shards, causing sentinel values to leak into min/max results.

The two APIs have different sentinel behavior when a shard has no data for the field:

• PointValues.getMinPackedValue() returns null when there are no points: callers can check for null and skip.
• DocValuesSkipper.globalMinValue() returns Long.MIN_VALUE when a leaf reader has no skipper, and Long.MAX_VALUE when no segments have the field. globalMaxValue() returns the opposite sentinels.

When hasDocValuesSkipper is determined from the first shard (e.g. a TSDB shard) and then applied to a standard shard that only has PointValues, globalMinValue/globalMaxValue are called on readers that have no skipper. This returns the sentinels Long.MIN_VALUE/Long.MAX_VALUE, which propagate as the min/max result.

This replaces the workaround in #142726 which filtered sentinels after the fact with hasMin/hasMax booleans. Instead, this fix addresses the root cause: min() and max() now always call the right API based on each shard's own DateFieldType.hasDocValuesSkipper(), using doc values skippers when available and BKD trees (point values) otherwise, rather than deriving the choice once from the first shard and applying it globally. This way sentinels can never leak in the first place.

What changed

• min() and max() now iterate contexts directly instead of using doWithContexts, preserving the context-to-leaf-reader association needed to check hasDocValuesSkipper() per shard. Each shard always uses the correct API to retrieve min/max values: doc values skippers when available, BKD trees (point values) otherwise.
• Simplified the early-return guard: removed the (hasDocValueSkipper == false && stat.config.indexed == false) check which was incorrect for mixed TSDB/standard environments (a TSDB shard with indexed=false would cause the global indexed to be false, bailing out even when standard shards have points)
• Extracted helper methods (docValuesSkipperMinValue/docValuesSkipperMaxValue and pointMinValue/pointMaxValue) that wrap the underlying APIs and convert sentinel values to null. This gives both code paths a uniform Long-or-null interface, and also filters the Long.MIN_VALUE sentinel from DocValuesSkipper.globalMinValue() that the previous code did not guard against. The per-leaf results are aggregated via nullableMin/nullableMax helpers.

Tests

• testPointValuesMinMaxDoesNotReturnSentinelValues: exercises the PointValues code path. Creates multiple standard (non-TSDB) contexts where the date field is mapped but has no actual date data. Asserts hasDocValuesSkipper() is false on each context and verifies that min() and max() return null as expected. This is the path that reproduces the original stack trace: without the fix, Long.MAX_VALUE leaks as min and Long.MIN_VALUE as max, causing Rounding.prepare(min, max) to throw IllegalArgumentException: [9223372036852975807] must be <= [-9223372036852975808].

• testDocValuesSkipperMinMaxDoesNotReturnSentinelValues: exercises the DocValuesSkipper code path. Creates multiple TSDB contexts where @timestamp is mapped with hasDocValuesSkipper()=true but the Lucene index only contains keyword docs (no timestamp data written). Verifies that min() and max() return null instead of sentinel values. In practice, data streams always have @timestamp populated, but the test intentionally forces the empty-data corner case so that the sentinel handling is self-contained and does not rely on guarantees from upper layers.

Replaces #142726

Closes #142725

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[romseygeek]

LGTM. I wonder if we need to build a more general 'get min and max values of a field' API directly into lucene here?

[romseygeek]

Given that we know we're operating on a DateFieldType here (because of the instanceof check on line 236) we can use ctxFieldType.indexType().hasSkippers() directly here.

[salvatore-campagna]

Right...no instanceof 💯

[salvatore-campagna]

LGTM. I wonder if we need to build a more general 'get min and max values of a field' API directly into lucene here?

Yeah I think it would be better to have something like that. Whatever the underlying data structure is, just give me min/max.

[salvatore-campagna]

I opened this issue in Lucene too: apache/lucene#15740