Add tiebreaker to stats sort-on-measure IT queries

[ahkcs]

Summary

Six tests in StatsCommandIT assert a specific top-K cutoff for queries like | stats … by X | sort - count() | head 5. When count() has ties at the cutoff, PPL spec doesn't define a tiebreaker, so different execution engines (legacy DSL terms-agg, Calcite enumerable sort, analytics-engine hash sort) return different tied rows. The strict containsInAnyOrder assertion only happened to match whichever member the original engine picked.

Address by adding the group-by column(s) as an explicit secondary sort key. The query is now deterministic regardless of engine, and the existing strict assertion can stay. Per @penghuo's review feedback on an earlier revision, this fixes the root cause rather than masking it with a tie-tolerant matcher.

Tests changed (in StatsCommandIT)

Test	Query change
testStatsSortOnMeasure Q1 + Q2	sort - count(), state | head 5 / sort count(), state | head 5
testStatsSortOnMeasureWithScript Q1 + Q2	sort - count(), new_state | head 5 / sort count(), new_state | head 5
testStatsSpanSortOnMeasure Q1 + Q2	sort - cnt, \span(birthdate,1month)` | head 5/sort cnt, `span(birthdate,1month)` | head 5`
testStatsSpanSortOnMeasureMultiTerms Q1 + Q2	sort - count(), gender, state | head 5 / sort count(), gender, state | head 5
testStatsSpanSortOnMeasureMultiTermsWithScript Q1 + Q2	sort - count(), new_gender, new_state | head 5 / sort count(), new_gender, new_state | head 5
testStatsSortOnMeasureComplex Q1 + Q2	sort - c, state | head 5 / sort - d, gender, new_state | head 5

Where the original test had separate pushdown / no-pushdown / non-Calcite branches asserting different tied alternatives, all branches collapse into a single expected ordering once the tiebreaker is added.

Verification

CalciteStatsCommandIT (default Calcite-DSL path) against the local cluster:

./gradlew :integ-test:integTestRemote \
  -Dtests.rest.cluster=localhost:9200 -Dtests.cluster=localhost:9300 -Dtests.clustername=runTask \
  --tests "org.opensearch.sql.calcite.remote.CalciteStatsCommandIT"
→ 63 / 63 pass

Test plan

• ./gradlew :integ-test:compileTestJava clean.
• Spotless clean.
• CalciteStatsCommandIT against a default-routed (non-analytics) cluster: 63 / 63 pass.
• CI on this PR.

[penghuo]

Why not just modify the query and add another sort column as a tiebreaker? PPL spec does not define tiebreaker.

When the IT was first written, the author likely didn't realize the PPL query produces non-deterministic results when measure values tie. Adding a deterministic tiebreaker (e.g. sort - count(), state) fixes the root cause

[ahkcs]

Good call — applied. Rewrote the PR to drop the verifyDataRowsAllowingTiesAt matcher and instead added an explicit tiebreaker (the group-by column) to each of the six queries' sort clauses, restoring the strict verifyDataRows assertions with the deterministic expected rows.

For the queries that had separate pushdown / no-pushdown / non-Calcite branches asserting different tied alternatives, all branches now collapse to a single expected ordering. CalciteStatsCommandIT against the default Calcite-DSL path: 63 / 63 pass.