### 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_
server/src/main/java/org/elasticsearch/TransportVersion.java
* <p>
 * Each version constant has a unique id string. This is not actually used in the binary protocol, but is there to ensure
 * each protocol version is only added to the source file once. This string needs to be unique (normally a UUID,
 * but can be any other unique nonempty string).
 * If two concurrent PRs add the same transport version, the different unique ids cause a git conflict, ensuring the second PR to be merged
 * must be updated with the next free version first. Without the unique id string, git will happily merge the two versions together,
 * resulting in the same transport version being used across multiple commits,
 * causing problems when you try to upgrade between those two merged commits.
 * <h2>Version compatibility</h2>
 * The earliest compatible version is hardcoded in the {@link #MINIMUM_COMPATIBLE} field. Previously, this was dynamically calculated
 * from the major/minor versions of {@link Version}, but {@code TransportVersion} does not have separate major/minor version numbers.
 * So the minimum compatible version is hard-coded as the transport version used by the highest minor release of the previous major version.
 * {@link #MINIMUM_COMPATIBLE} should be updated appropriately whenever a major release happens.
 * <p>
 * The earliest CCS compatible version is hardcoded at {@link #MINIMUM_CCS_VERSION}, as the transport version used by the
 * previous minor release. This should be updated appropriately whenever a minor release happens.
 * <h2>Adding a new version</h2>
 * A new transport version should be added <em>every time</em> a change is made to the serialization protocol of one or more classes.
 * Each transport version should only be used in a single merged commit (apart from BwC versions copied from {@link Version}).
 * <p>
 * To add a new transport version, add a new constant at the bottom of the list that is one greater than the current highest version,
 * ensure it has a unique id, and update the {@link CurrentHolder#CURRENT} constant to point to the new version.
 * <h2>Reverting a transport version</h2>
 * If you revert a commit with a transport version change, you <em>must</em> ensure there is a <em>new</em> transport version
 * representing the reverted change. <em>Do not</em> let the transport version go backwards, it must <em>always</em> be incremented.
 */
public record TransportVersion(int id) implements Comparable<TransportVersion> {
    /*
     * NOTE: IntelliJ lies!
     * This map is used during class construction, referenced by the registerTransportVersion method.