fix: Coerce aggregate FILTER predicates to boolean

[pchintar]

Which issue does this PR close?

• Closes Aggregate FILTER fails on NULL predicate #22773 .

Rationale for this change

Aggregate and window aggregate FILTER clauses currently fail with an internal error when the filter condition is NULL, even though the equivalent boolean-typed expression (e.g. CAST(NULL AS BOOLEAN)) works correctly.

This occurs because FILTER predicates are not being coerced to BOOLEAN during type coercion.

What changes are included in this PR?

• Coerce aggregate FILTER predicates to BOOLEAN during type coercion.
• Apply the same coercion to window aggregate FILTER predicates.
• Add SQL logic tests covering FILTER (WHERE NULL) for both aggregate and window aggregate functions.

Are these changes tested?

Yes.

Added SQL logic tests covering:

• COUNT(*) FILTER (WHERE NULL)
• COUNT(1) FILTER (WHERE NULL)
• SUM(1) FILTER (WHERE NULL)
• AVG(1) FILTER (WHERE NULL)
• Window aggregate variants using FILTER (WHERE NULL)

Are there any user-facing changes?

Yes.

Queries using FILTER (WHERE NULL) no longer fail with an internal error and now return the expected results. Also, no changes were made to any public APIs

[nuno-faria]

Thanks @pchintar, LGTM.

Just a small note: predicates like select count(*) filter (where 1) are also converted to bool. DuckDB follows the same logic, while Postgres returns an error. I'd say this is ok.

[nuno-faria]

Should these be moved to window.slt? On the other hand there are already other window function tests at aggregate.slt, so I'm not sure what is the criteria.

[pchintar]

Thanks @nuno-faria , and thanks for checking the predicate behavior against DuckDB/Postgres too.

I put these in aggregate.slt because the failure is in aggregate FILTER handling and there are already related aggregate/window aggregate cases here. So, Keeping the new cases alongside the existing aggregate FILTER coverage felt more consistent to me.

[alamb]

thanks @pchintar and @nuno-faria