fix(optimizer): type nested set operations pairwise and by position - #8702

Currently, types for nested set operations are taken from the leftmost query and merged by name, so types in the nested operation are not properly bubbled up.

For example, in this query annotate_types infers t.a as INT, while Postgres (double precision) and DuckDB (DOUBLE) both report a double:

SELECT 
  t.a 
FROM (
  SELECT 
    1 AS a 
  UNION ALL (
    SELECT 
      2 AS b 
    UNION ALL 
    SELECT 
      2.5::DOUBLE AS c
  )
) AS t

Cause

• Each set operation compares this.selects with expression.selects. For a parenthesized operand, Subquery.selects returns only the projections of its first query (SELECT 2 AS b). The outer UNION therefore never sees the DOUBLE.
• Every set operation in the tree writes its result into one shared dict, keyed by its own left query's column names. The inner UNION computes DOUBLE correctly, but stores it under b, which the outer column a never reads.

Left-nested chains currently work only because every operation's left query is the same first query, so the names always line up.

Fix

Resolve set operations pairwise and bottom-up:

• Set operations are resolved in reverse walk() order, so nested operations resolve before the ones containing them.
• A parenthesized operand contributes its own resolved columns rather than its first query's selects.
• Columns match by position (by name for BY NAME), and output names come from the left operand.
• A column-count mismatch inside the tree now gives anUNKNOWN type rather than the first query's type.