…tions

Both broken identities in the catalog get the NULL/empty boundary backwards, in
opposite directions, and both produce false positives whenever the generated
condition selects no row - which the fuzzer hits constantly, since a random
predicate over a small generated table is often false or NULL everywhere.

sumIf: the rewrite was `sum(if(cond, x, 0))`. With
aggregate_functions_null_for_empty=1, which this identity pins, `sumIf` returns
NULL when the condition holds for no row, while the `0` else branch feeds a real
value into `sum` for every row and returns 0. Its siblings `minIf` and `maxIf`
already use `NULL` as the else branch; `sumIf` was the odd one out. Measured on
26.9:

    SELECT sumIf(c, c IS NOT NULL)          FROM (SELECT NULL AS c)  -- \N
    SELECT sum(if(c IS NOT NULL, c, 0))     FROM (SELECT NULL AS c)  -- 0   mismatch
    SELECT sum(if(c IS NOT NULL, c, NULL))  FROM (SELECT NULL AS c)  -- \N  agrees

countIf: the rewrite was `sum(toUInt64(cond))`. This is the mirror mistake - when
`cond` is Nullable and NULL for every row (or the input is empty), the argument is
NULL throughout and `sum` returns NULL, while `countIf` returns 0. Guard the
condition with `ifNull(cond, 0)`, which also matches countIf's own treatment of a
NULL condition as false and is a no-op when the condition is already non-Nullable:

    SELECT countIf(c)                       FROM (SELECT NULL AS c)  -- 0
    SELECT sum(toUInt64(c))                 FROM (SELECT NULL AS c)  -- \N  mismatch
    SELECT sum(toUInt64(ifNull(c, 0)))      FROM (SELECT NULL AS c)  -- 0   agrees

Both replacements were checked against the cases the fuzzer can produce: empty
input, condition false for every row, condition NULL for every row, value NULL
under a true condition, and mixed rows including negatives and zero. The other
four identities (minIf, maxIf, sumOrNull, avgOrNull) agree in all of them and are
left alone.

The two exact-string assertions that pinned the old forms are updated, plus two
new tests that lock the property rather than the string: every `if`-family rewrite
must use NULL as its else branch, and the countIf rewrite must null-guard its
condition.

This is the ClickHouse-side finding it was producing (SQLancer nightly,
2026-08-25, TLPCombinator, 1 of 87 findings):

    First query : SELECT sumIf(right_1.c0, (right_1.c0 IS NOT NULL)) FROM ...
    Second query: SELECT sum(if((right_1.c0 IS NOT NULL), right_1.c0, 0)) FROM ...
    It misses: "[0]"