[Jaden-Varkey]

Which issue does this PR close?

• Closes Internal error (nullability mismatch) when aggregating over CASE WHEN a < b THEN a ELSE ... END #26284.

Rationale for this change

SELECT DISTINCT CASE WHEN a < b THEN a ELSE 1 END FROM n (and the sum/UNION variants in the issue) fails with "Physical input schema should be the same as the one converted from logical input schema" because the logical and physical planners disagree on the CASE's nullability.

The logical side (predicate_bounds::is_null) knows NULL < b is always NULL, so the THEN a branch is never taken when a is NULL and the result is non-nullable. The physical evaluate_predicate can't constant-fold NULL < b (it still references b) and falls back to ANY_TRUTH_VALUE, so the result is nullable. Existing tests only used predicates that constant-fold (a > 1, a IS NOT NULL).

What changes are included in this PR?

evaluate_predicate now returns UNKNOWN when the predicate is certainly NULL: a NULL literal, a returns_null_on_null() binary op with a certainly-NULL operand, or NOT/-/CAST of one. This mirrors the logical is_null, and follows the same sync approach as unwrap_certainly_null_expr (#23844).

What is the testing strategy for this PR?

• test_case_expression_nullability_with_column_comparison in case.rs: non-nullable for a < b, a + 1 < b, CAST(a) < CAST(b); still nullable for IS DISTINCT FROM and a < b OR b IS NULL.
• The three queries from the issue in case.slt.
  Both fail on main and pass with the fix.

Are there any user-facing changes?

No, other than those queries no longer erroring.

AI-assisted (Claude). I've reviewed the change.