fix(optimizer): Drop a redundant COALESCE in decorrelation

[mbasmanova]

Summary:
Decorrelating a correlated count(*) subquery wrapped the aggregate in COALESCE(count, 0) on every path, so a filter over it planned as

gt(coalesce("count15", 0), 3)

In the lifted shape that wrap is dead work: the aggregate runs above a LEFT join and groups by the outer row id, so an outer row with no matches still forms a group, and a masked count over that empty group already returns 0. The filter now plans as gt("count", 3).

buildAggregateWraps takes everyOuterRowHasGroup. The three lifted shapes pass true and skip the wrap; the join-back shape keeps it, because there an unmatched outer row has no group at all and the LEFT rejoin pads it with NULL.

With the wrap gone, six assertions across the nonEqui* subquery tests now pin v2 instead of v1. Three stay on v1 where v2 is worse: the equi-and-non-equi correlation builds the hash join on the outer relation and loses the streaming aggregation, and both distributed cases split the per-outer-row aggregation into PARTIAL and FINAL around a HASH(__rownum) shuffle, though each group holds one row.

Found along the way and not fixed here, v1 answers this query wrong:

SELECT a, (SELECT count(*) FROM u WHERE u.a = t.a HAVING count(*) = 0) AS c FROM t

For an outer row whose subquery matched but failed the HAVING, v1 returns 0 where the answer is NULL. Its own COALESCE on the join-back path cannot tell that row apart from one with no matches at all, since both reach the rejoin as NULL. v2 and DuckDB agree on NULL. A fix needs the HAVING applied above the restored empty-input value, so it is not a local change.

Differential Revision: D117590410

[meta-codesync]

@mbasmanova has exported this pull request. If you are a Meta employee, you can view the originating Diff in D117590410.