fix: TopK aggregation drops groups whose MIN/MAX value is NULL

[u70b3]

Which issue does this PR close?

• Closes Wrong result: grouped MAX(NULL) row is dropped with ORDER BY aggregate NULLS FIRST LIMIT #23440
• Closes DataFusion drops grouped MIN/MAX rows with NULL sort keys under ORDER BY + LIMIT #22190

Rationale for this change

When TopKAggregation pushes a LIMIT into a MIN/MAX aggregate, a group whose aggregate inputs are all NULL can disappear instead of being returned with a NULL aggregate value.

The stream previously skipped NULL aggregate inputs without registering the group. This is correct for an individual MIN/MAX input, but not for a group whose inputs are all NULL.

There is also an important correctness boundary: nullable MIN/MAX with NULLS FIRST is not monotonic for a bounded aggregation. A group can start at NULL, later become non-NULL, and thereby move to a worse rank. Keeping only limit NULL candidates can therefore discard a group that belongs in the final result.

What changes are included?

• Track up to limit all-NULL candidates alongside valued TopK groups and emit them for the parent sort to rank and truncate.
• Correctly convert a tracked NULL group when its first value arrives, or unregister it when that value cannot enter the valued TopK.
• Skip TopK pushdown for nullable MIN/MAX with NULLS FIRST; regular aggregation is used for exact results. TopK remains enabled for NULLS LAST, non-nullable MIN/MAX inputs, and GROUP BY-only/DISTINCT queries.
• Replace the single reusable hash-table slot with a free-slot stack. A NULL-to-value conversion can free both the NULL registration and an evicted valued group, so retaining only one slot caused unbounded backing-store growth under repeated conversions.
• Select NULL-aware insertion once per batch, keeping NULL bookkeeping off the common no-NULL per-row hot path.
• Add regression coverage for all-NULL groups, mixed NULL/value batches, bounded NULL candidate backfill, evicted groups, hash-table slot reuse, and optimizer plan selection.

Are these changes tested?

Yes. The following passed on the final commit:

• cargo fmt --all -- --check
• cargo clippy --all-targets --all-features -- -D warnings
• TopK physical-plan unit tests (33 tests)
• aggregates_topk.slt and affected group_by.slt tests
• The repository's extended workspace command with avro,json,backtrace,extended_tests,recursive_protection,parquet_encryption, including all 495 sqllogic files and extended/fuzz suites

Performance

The topk_aggregate 10-million-row time-series benchmark exposed an initial ~5.5% regression from checking NULL state on every row. Moving NULL handling to a batch-selected slow path removed the measurable regression.

Final 30-sample 95% intervals on the same machine and settings:

• main: 25.630–26.436 ms
• this PR: 25.151–27.061 ms

Are there any user-facing changes?

Queries that previously dropped all-NULL groups under ORDER BY <min/max> ... LIMIT now return correct SQL results. Nullable MIN/MAX queries using NULLS FIRST may use regular aggregation rather than the bounded TopK optimization to guarantee correctness. There are no API or configuration changes.