fix: validate clause expressions during logical planning

[myandpr]

Which issue does this PR close?

• Closes More type checking at logical planning #20356.

Rationale for this change

SELECT 1 + 'a' fails during logical planning, but equivalent invalid expressions in WHERE, HAVING, QUALIFY, ORDER BY, and JOIN ... ON were still deferred until later phases.

This PR fixes that inconsistency in the SQL planner. It only adds earlier validation for these SQL clauses, and does not change the analyzer/type coercion design for other planning paths.

What changes are included in this PR?

• add eager expression validation in the SQL planner
• apply it to WHERE, HAVING, QUALIFY, ORDER BY, and JOIN ... ON
• recursively validate clause expressions so wrapped invalid expressions such as STARTS_WITH() IS NULL are also rejected during logical planning

Are these changes tested?

Yes.

Added regression tests for:

• direct invalid expressions such as (1 + 'a')
• wrapped invalid expressions such as (STARTS_WITH() IS NULL)

These tests cover WHERE, HAVING, QUALIFY, ORDER BY, and JOIN ... ON.

Are there any user-facing changes?

Yes. Invalid expressions in these clauses now fail earlier during logical planning.

[myandpr]

Hey @alamb , Could you please help trigger CI for this PR? This is my first contribution here.

I’m hoping to contribute more actively to the project going forward, so I’d really appreciate your help. Thanks!

[alamb]

Thanks for the contribution @myandpr 🙏

[alamb]

most DataFusion type validation happens during the Analyzer phase, not the sql planner (binding phase)

I agree with @Acfboy s original statement that failing at physical planning time is probably too late, but trying to do this in sql is too early

Among other things it means that this type checking will not apply to queries created via the DataFrame API

[myandpr]

Thanks @alamb , that makes sense.

I agree that doing this in the SQL planner makes the behavior SQL-specific and misses queries built through the DataFrame API.

I’ll rework this toward the analyzer/type coercion path instead, and I’ll take a closer look at which cases are already covered there versus which ones still need to be handled. I’ll also update the regression tests to match that direction.