fix(unparser): unparse a stacked aggregate as a derived table

[claudespice]

Summary (root cause)

A SELECT expresses a single grouping, but the LogicalPlan::Aggregate arm of
select_to_sql_recursively recursed straight into its input whenever the select list had
already been built (select.already_projected()), so a second aggregate stacked
underneath was skipped entirely — its GROUP BY never reached the emitted SQL. The
Sort, Limit, Distinct and Projection arms all guard the same situation by emitting
a derived table; Aggregate did not.

single_distinct_to_groupby produces exactly that shape for count(DISTINCT c): an outer
count(alias1) over an inner Aggregate grouping by c AS alias1. Unparsing the
optimized plan for SELECT count(DISTINCT "UserID") FROM hits therefore emitted

SELECT count(alias1) AS c FROM hits          -- inner GROUP BY silently gone

Two consequences, both bad:

1. alias1 does not exist on the base table, so a consumer that pushes the optimized plan
   down to a remote engine gets a binder error (Referenced column "alias1" not found in FROM clause). This is the failure reported downstream in DuckDB agg pushdown: Clickbench/aliasing issues spiceai#8475 against
   ClickBench q5 on DuckDB.
2. Where a column of that name does exist, the statement binds and the DISTINCT is
   silently gone — count(alias1) counts every row.

Changes

• SelectBuilder tracks whether an aggregate has been folded into the current SELECT
  (mark_aggregated() / already_aggregated()).
• The Aggregate arm emits a derived_aggregate table for a second aggregate instead of
  skipping it, matching the existing derived_sort / derived_limit / derived_distinct /
  derived_projection handling.

After the fix:

SELECT count(alias1) AS c FROM (SELECT hits."UserID" AS alias1 FROM hits GROUP BY hits."UserID")

Why the existing roundtrip suites missed it

datafusion/core/tests/sql/unparser.rs runs the TPC-H and ClickBench queries through
df.logical_plan() — the plan as the SQL planner produces it, before
single_distinct_to_groupby runs. The rewrite only appears in the optimized plan, which
is what a federation/pushdown consumer unparses. The new test closes that gap.

Test plan

• cargo test -p datafusion-sql — stacked_aggregate_is_unparsed_as_a_derived_table
  covers the ungrouped count(DISTINCT b) shape, the grouped
  a, count(DISTINCT b) ... GROUP BY a shape, and a lone aggregate (which must still fold
  into its SELECT rather than become a derived table).
  Result: 498 passed / 22 failed, versus 497 / 22 on a pristine checkout of this
  base — the same 22 pre-existing failures, byte-identical output, plus the new test.
• cargo test -p datafusion --test core_integration sql:: —
  test_optimized_plan_roundtrip_count_distinct unparses the optimized plan for
  count(DISTINCT) with and without a GROUP BY, then executes both the original and the
  unparsed SQL against the ClickBench fixture and compares the rows.
  Result: 71 passed / 29 failed, versus 70 / 30 on the same base — the only delta
  is the new test flipping from failing to passing.
• Neutering check: with plan.rs reverted, both new tests fail, and the core test fails
  with column 'alias1' not found and the emitted SQL
  SELECT count(alias1) AS c FROM hits_raw AS hits — i.e. it reproduces the reported bug.

Downstream issue: spiceai/spiceai#8475