fix: handle NULLs in sliding SUM(DISTINCT) window frames

[kumarUjjawal]

Which issue does this PR close?

• Closes SUM(DISTINCT) over a bounded window frame ignores NULLs' validity mask and returns 0 instead of NULL #22754

Rationale for this change

SUM(DISTINCT) over bounded/sliding window frames did not handle NULL values correctly.

It could read values from null slots in the Arrow buffer, and it returned 0 instead of NULL when a frame had no non-null values.

What changes are included in this PR?

• skip NULL rows in sliding SUM(DISTINCT) update
• skip NULL rows in sliding SUM(DISTINCT) retract
• return NULL when the frame has no non-null distinct values
• reuse the same helper for distinct-value updates during merge
• add regression tests for accumulator behavior with null slots
• add sqllogictest coverage for sliding window SQL behavior, including when a frame becomes all NULL

Are these changes tested?

Yes

Are there any user-facing changes?

SUM(DISTINCT) over bounded/sliding window frames now handles NULL values correctly:

• NULL inputs are ignored
• frames with no non-null values return NULL instead of 0
• No API Change

[kosiew]

@kumarUjjawal
Thanks for the fix. This looks good and I only have one small suggestion.

[kosiew]

Nice cleanup overall. One small thought: the NULL-aware iteration logic looks very similar between update_batch and retract_batch. Would it make sense to extract a small helper that keeps the current no-null fast path and accepts the value operation, something like apply_valid_values(values, Self::update_value) and apply_valid_values(values, Self::retract_value)?

That would keep the invariant that only valid slots affect counts and sum in one place and help avoid the two paths drifting apart over time.

[kumarUjjawal]

Thanks you @kosiew