prestodb#27903)

## Summary

`protocol::AggregationNode::aggregations` is `std::map<VRE,
Aggregation>` on the native side (sorted by variable name); the Java
side iterates `LinkedHashMap` insertion order. When the two orders
diverge — e.g. `approx_distinct_*` mixed with `sum_*`, alphabetical sort
`approx_distinct < sum` but Java inserts `sum`s first — the native
`AggregationNode` output schema differs from the Java planner's. Channel
positions shift and type mismatches surface at exchange operators:

```
type_->kindEquals(vector.type()) Type mismatch: BIGINT vs. DOUBLE
Operator: LocalPartition(...)
```

prestodb#27493 partially addressed this by switching three Java optimizer rules
from `HashMap` to `LinkedHashMap` (deterministic insertion order), but
did not align Java with the native side's sort. Queries whose variable
names happened to sort consistently with their insertion order passed;
others still crashed.

This adds an explicit `aggregationOutputs:
List<VariableReferenceExpression>` field, populated on the Java side
from `aggregations.keySet()` in `LinkedHashMap` order. The native
converter uses this list when present and falls back to `std::map`
iteration only for older coordinators that don't send the field (so
rolling upgrades are safe).

Fixes prestodb#27902.

## Changes

- `presto-spi/.../AggregationNode.java`: `@JsonProperty(READ_ONLY)
getAggregationOutputs()` — derived from `aggregations`, no constructor
change.
- `presto_protocol_core.h`/`.cpp`: `List<VRE> aggregationOutputs` on
`protocol::AggregationNode`, with backward-compatible `from_json`.
- `PrestoToVeloxQueryPlan.cpp`: converter uses `aggregationOutputs` when
non-empty; falls back to map iteration otherwise.
- Tests: protocol round-trip + backward-compat
(`AggregationNodeTest.cpp`); Java getter ordering
(`TestPreAggregateBeforeGroupId`).

## Test plan

- [ ] `mvn test -pl presto-main-base
-Dtest=TestPreAggregateBeforeGroupId#testAggregationOutputsPreservesInsertionOrder`
- [ ] `presto-native-execution` build + run `presto_protocol_test
--gtest_filter="AggregationNodeTest.*"`
- [ ] Existing `TestPreAggregateBeforeGroupId` suite stays green
- [ ] Manually verify a reproducer query (`approx_distinct(...)` +
`sum(...)` under `GROUPING SETS` with
`optimizer.pre_aggregate_before_grouping_sets=true`) no longer crashes
on a Prestissimo cluster

## Release notes

\`\`\`
== RELEASE NOTES ==

Native Execution Changes
* Fix runtime type-mismatch crashes at exchange operators in Prestissimo
when aggregation variable names sort differently from their Java
allocation order. The protocol now carries an explicit aggregation
output ordering so native workers build the AggregationNode output
schema in the order the Java planner intended.
\`\`\`

## Summary by Sourcery

Ensure native AggregationNode output schemas follow Java planner
aggregation ordering by explicitly propagating aggregation output
variables through the protocol and converter.

Bug Fixes:
- Prevent type-mismatch failures in native execution caused by differing
aggregation iteration orders between Java and C++.

Enhancements:
- Expose an explicit aggregationOutputs list on AggregationNode in the
Java SPI and carry it through the native protocol for deterministic
aggregation output ordering.

Tests:
- Add Java and C++ regression tests to verify aggregation output
ordering is preserved and that the protocol remains backward compatible
when aggregationOutputs is absent.