### Elasticsearch Version

8.9.0

### Installed Plugins

_No response_

### Java Version

_bundled_

### OS Version

all

### Problem Description

In https://github.com/elastic/elasticsearch/pull/96953 we added support for a much more memory efficient algorithm that relies on the time-ordering and grouping provided by the time-series aggregation in TSDB. However, this work only covered the data nodes, and the reduce phase in the coordinating nodes that merges geo_lines does not take this into account, leading to unexpected truncation of long geo_lines.

### Steps to Reproduce

Easiest to reproduce by setting the shard size small, loading very long geolines that will be composed of many data points over many shards, and then setting the geo_line aggregation size to a small size. The final lines will not include the two end points as they should, but be truncated.

### Logs (if relevant)

_No response_
x-pack/plugin/spatial/src/main/java/org/elasticsearch/xpack/spatial/search/aggregations/TimeSeriesGeoLineBuckets.java
* objects between each bucket collection phase.
     */
    InternalGeoLine buildInternalGeoLine(String name, Map<String, Object> metadata, boolean includeSorts, SortOrder sortOrder) {
        LineStream line = simplifier.produce();
        boolean complete = simplifier.length() < bucketSize;
        
        double[] sortVals = line.sortValues;
        long[] bucketLine = line.encodedPoints;
        if (sortOrder == SortOrder.ASC) {
            
            ArrayUtils.reverseSubArray(sortVals, 0, sortVals.length);
            ArrayUtils.reverseSubArray(bucketLine, 0, bucketLine.length);
        }
        return new InternalGeoLine(name, bucketLine, sortVals, metadata, complete, includeSorts, sortOrder, bucketSize);
    }
    /**
     * In the aggregation phase we need to return the InternalGeoLine aggregation objects for each bucket.
     * Since the collect phase was re-using the same memory for each bucket during collection, the construction
     * of all InternalGeoLine aggregations was done at the end of each bucket collection, and here we merely
     * return the results.
     */
    public InternalAggregation getGeolineForBucket(long bucket) {
        return geoLines.get(bucket);
    }
    /**
     * Wrapper for points and sort-fields that are also usable in the GeometrySimplifier library.
     * Since that library has no knowledge of timestamps or sort-fields, we need to use these custom objects
     * to maintain the geo_point-timestamp correlation through the simplification process.
     */
    private static class SimplifiablePoint extends StreamingGeometrySimplifier.PointError {