Fix aggregate FILTER subquery scheduling

[HavAnIdea]

Description

Fixes #6807.

This fixes a panic when a grouped HAVING/ORDER BY aggregate FILTER predicate contains an IN (SELECT ...) subquery. Those subqueries were being scheduled for grouped-output evaluation, but aggregate filters run while rows are accumulated, before grouped output opens the IN subquery's ephemeral cursor.

The patch keeps subqueries referenced by aggregate args or aggregate FILTER predicates on the pre-aggregation evaluation path. It also lets non-correlated IN subquery expressions inside aggregate filters continue walking their left-hand side while collecting GROUP BY sorter leaf columns, so the filter reads row values from the pseudo cursor during aggregation instead of a stale base-table cursor.

Motivation and context

The issue reproducer panicked with cursor id 0 is None instead of matching SQLite behavior. The added regression tests cover both the constant reproducer from #6807 and the grouped sorter case where the FILTER predicate depends on a grouped input column.

Validation

• rustfmt --check core/translate/subquery.rs core/translate/group_by.rs
• git diff --check
• make -C testing/sqltests run-rust ARGS='--filter grouped-having-aggregate-filter-constant-in-subquery'
• make -C testing/sqltests run-rust ARGS='--filter grouped-having-aggregate-filter-empty-in-subquery'
• make -C testing/sqltests run-rust ARGS='--filter grouped-having-aggregate-filter-column-in-subquery'
• cargo +stable run -q -p differential-fuzzer --bin differential_fuzzer -- --seed 735188941686177792 -n 220 -t 3 -c 5 -g sql-gen --keep-files

Description of AI Usage

I used Codex to help reduce the fuzzer panic, inspect query translation paths, implement the targeted fix, and run the validation commands above. I reviewed the resulting diff and kept the change scoped to subquery scheduling/aggregate filter GROUP BY handling plus regression tests.

[github-actions]

Fossier: Manual Review Requested

@havanidea is a new contributor. A maintainer should review this PR before merging.

Score Breakdown

Total Score: 50.4/100 | Confidence: 100% | Outcome: REVIEW

Signal	Value	Score	Weight
account_age	2736	1.00	0.07
public_repos	21	1.00	0.04
contribution_history	21	0.10	0.04
follower_ratio	1.0	0.50	0.04
bot_signals	False	0.50	0.03
open_prs_elsewhere	1	0.88	0.07
closed_prs_elsewhere	0	1.00	0.08
merged_prs_elsewhere	0	0.20	0.06
prior_interaction	0	0.00	0.24
activity_velocity	1	1.00	0.06
pr_content	...	1.00	0.06
commit_email	no_email	0.50	0.03
pr_description	...	0.70	0.04
repo_stars	19121	0.30	0.03
org_membership	0	0.20	0.02
commit_verification	...	0.30	0.03
contributor_stars	0	0.00	0.03

[HavAnIdea]

Quick verification update for reviewers:

• Fossier requested manual review because this is my first Turso PR.
• Local verification before opening the PR passed: targeted sqltests for the three added regression cases, rustfmt --check, git diff --check, and a 220-statement differential fuzzer run.
• GitHub CI is now green across the main Rust/sqltest/build/test jobs I checked; only CodSpeed-style benchmark reporting was still pending on the last check.

Happy to adjust the regression shape or move the tests if maintainers prefer a narrower fixture.