GROUP BY without an aggregate in the SELECT list returns per-document rows instead of one row per group (silent wrong answer)

[fupelaqu]

Found by Epic 19 / Story 19.4's fixture sanity check; #205-family adjacent (silent wrong answer, not an error).

Repro (through the shipped es8 JDBC driver, plain jdbc:elastic://, ES 8.18.3)

Fixture: bi_events, 200,000 docs, 3 shards, category keyword with exactly 100 distinct values (cat_000..cat_099).

SELECT category, COUNT(*) AS c FROM bi_events GROUP BY category
-- 100 rows, one per bucket: correct

SELECT category FROM bi_events GROUP BY category
-- 10,000 rows; the first rows are all the SAME category value

The aggregate-free form returns per-DOCUMENT rows (10,000 = a result-window-shaped cap, and duplicates within each group), not one row per group. Nothing fails — the caller gets a complete-looking, silently wrong answer, and the row count changes with the fixture, not with the group count.

Standard SQL semantics for SELECT category ... GROUP BY category is one row per group (it is the idiomatic DISTINCT). BI tools generate exactly this shape for dimension-member enumeration (e.g. filter dialogs).

Suspected locus: the aggregation-shaped vs row-shaped routing — with no aggregate in the SELECT list the statement appears to be executed as (or flattened into) a document query instead of a terms aggregation. Compare #205/#209's returnsRows discriminator work.

Expected: either one row per group (preferred), or a loud rejection — never 10,000 silent per-document rows.