[SQL] Support JOIN on ROW types using IS NOT DISTINCT FROM - #6796

Solid piece of work. The choice to reject =/<>/!= on ROW values rather than silently switch semantics is the right call — the three-valued behaviour of the standard genuinely surprises users, and the alternative (matching our previous two-valued IS NOT DISTINCT FROM semantics) would have been a silent result-set change on existing programs.

Things I checked and like:

• The RejectRowEquality shuttle runs post-convertQuery on the RelRoot, which is the right place — Calcite's rewrites for IN, CASE, NULLIF, NATURAL/USING joins have already expanded to = by then, so all the implicit forms get caught. The test file covers each of these.
• Disabling the ROW-equality expansion in ConvertletTable.convertCall (commenting it out with the explanatory note) prevents it from firing before the shuttle sees the tree — otherwise (a,b) = (c,d) would decompose into field-wise equalities and slip through with a confusing error location. Nice.
• JoinConditionAnalyzer now converts key types with struct=false, which is what the surrounding key-tuple construction actually wants, and the UnimplementedException("Join on struct types", 3398, ...) guard is removed cleanly.
• The changelog explicitly calls this out as a breaking SQL change, and the Regression1Tests / RowComparisonTests cover the rewrite paths users will need.
• visitLogicalValues refactor into compileValues is a real fix for the "GC operators in the graph" bug you mention: the previous LogicalUnion loop silently dropped any input that wasn't a LogicalProject, so LogicalValues rows in a multi-row VALUES inserted via a modify statement went missing without error. Good to have that made loud (UnimplementedException on unknown inputs).

Two prose nits in the RejectRowEquality javadoc — feel free to ignore, they don't block:

• "A user-defined type is compiled a ROW type" — missing to/as.
• "Row equality is implied in JOIN conditions, a NATURAL JOINs, a USING clause" — stray a before NATURAL JOINs.

One larger thought, not a blocker: the error message points at the docs URL, which is great, but consider also naming the closest legal rewrite inline (... use 'IS NOT DISTINCT FROM' or its shorthand '<=>' instead) — you already do this for EQUALS/NOT_EQUALS. The NULLIF message is exemplary; the JOIN-condition path currently surfaces the plain EQUALS message which is fine but a hair less directive.

Approving.