### 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
}
    @Override
    public void close() {
        simplifier.reset();
    }
    /**
     * Since there is a different instance of the leaf collector for each segment, and within a segment
     * the bucket id can change (or tsid can change), we need to copy the streaming geometry simplifier memory
     * into an InternalGeoLine object before collecting the next bucket. This is handled by the Leaf.collect(doc,bucket)
     * method calling flushBucket(bucket) and any change in bucket id will copy the memory and prepare the simplifier
     * for the next bucket.
     */
    private void flushBucket(long bucket) {
        if (bucket != currentBucket) {
            if (currentBucket != NO_BUCKET) {
                if (geoLines.containsKey(currentBucket)) {
                    throw new IllegalStateException("Geoline already exists for bucket " + currentBucket);
                }
                geoLines.put(currentBucket, geoLineBuilder.get());
                simplifier.reset();
            }
            currentBucket = bucket;
        }
    }
    /**
     * Build the aggregation based on saved state from the collector phase.
     * Note that the collector phase does not know about sort-order, so if the order is not the native time-series
     * order of 'descending', this is where we can do an efficient in-place reverse ordering.
     * Also note that the collector phase will re-use the same memory (in the StreamingGeometrySimplifier) for each bucket,
     * so it is important that this method is called to copy that 'scratch' memory into the final InternalGeoLine aggregation