Filtered-aggregate sweep: RangeAgg and RangeIntersectAgg over groups whose inputs are filtered away, consumed by bounds, predicates, ??, ordering and HAVING #379

Problem

RangeAggregateParityTests compares RangeAgg/RangeIntersectAgg per group, projected. The result of an aggregate is then consumed: by a bound, a predicate, ??, an ordering and a group filter (HAVING), and a group can exist while a filter (g.Where(…), a filtered aggregate) removes all of its inputs. SQL's NULL for zero inputs (claim E07) then meets EF Core's nullability inference for the aggregate, which is where #349 and #361 lived.

Change

A sweep, FilteredAggregateProbeTests (integration project, a database of its own). Groups that are absent, present with no qualifying input, present with only NULL inputs, holding an empty range, and holding ordinary shapes. Aggregates inside the group filtered by a predicate, then consumed through LowerBound()/UpperBound() (against null and through ??), a predicate, ?? fallback, an OrderBy and a Where on the group (HAVING). The oracle is memory over the loaded rows, with the documented zero-input difference (E07: RangeAgg answers the empty set where SQL answers NULL) mapped, not reported. Disagreements go through Candidates.Verdict.

Done when

Registered in test/oracles/oracles.json with a seed it is shown to catch (aggregates-fold-a-null-input.patch where it applies); every disagreement is an issue and a candidates.json entry.