When `group_by_use_nulls` is enabled, expressions equal to GROUP BY keys
were matched with a comparison that ignored types
(`QueryTreeNodePtrWithHashIgnoreTypes`), because by the time an expression
is checked against `nullable_group_by_keys`, its subexpressions that are
themselves GROUP BY keys have already been converted to `Nullable`, so the
types no longer match the stored original key.

Instead, store in `nullable_group_by_keys` every shape in which an
expression equal to a key can arrive at the lookup: the original form, the
form with every maximal proper sub-key converted to `Nullable` (with the
types of the nodes above recomputed via `rerunFunctionResolve`), and the
key converted to `Nullable` itself. All shapes map to the original key
node, and the lookup uses exact comparison, including types. This allows
removing the `compare_types` option from `IQueryTreeNode::CompareOptions`
entirely, together with the half-dead ignore-types branch in
`ConstantNode::isEqualImpl`.

The type-blind comparison could conflate constants with equal values but
different types or source expressions. For example, in
`04001_logical_error_with_cube` the constant `1 AS a` inside a lambda was
replaced with a clone of a different key (`isNullable(2) IS NOT NULL`,
which folds to the same constant `1`), and the mangled projection then
constant-folded instead of reading the per-grouping-set key column. The
test reference captured this incorrect result; with exact matching the
projection correctly reads the key column, producing an additional row
with the default key value for the grouping set where the key is not
aggregated.

The exact matching now correctly replaces such projections with a clone of
the original key, which exposed a gap in the planner: the
already-computed-expression check in `PlannerActionsVisitor::visitFunction`
recognized only `INPUT` nodes, while a constant-foldable GROUP BY key
column arrives as a constant `COLUMN` node (constant inputs are duplicated
as `COLUMN` nodes by the `ActionsDAG` constructor). Visiting the arguments
of such a function builds a lambda capture over the original-typed
constant, which collides with the `Nullable`-wrapped key constant of the
same name and fails with a `Cannot capture column ... incompatible type`
exception. Extend the check to also recognize constant `COLUMN` source
nodes.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…y_use_nulls

A projection equal to a GROUP BY key is replaced with a Nullable clone of the
key from scope.nullable_group_by_keys. Two constants with equal value and type
but different source expressions collide in that map, since ConstantNode
equality and hashing ignore the source expression. The lookup cloned the stored
key, which could be a different colliding constant, giving the projection the
wrong source expression - and the source expression determines the planner
action node name, hence which aggregation key column the projection reads.

Clone the matched node itself for constants, preserving its own source
expression; non-constant keys still clone the stored canonical key so a
partially Nullable-converted shape keeps the matching action node name.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

This reverts commit d5a026d.