Regression: short floating-point IN lists mishandle signed zero #27121

Describe the bug

In 56.0.0-dev (1635ed9), floating-point IN lists containing two or three values distinguish -0.0 from +0.0. The same queries return correct results in 55.2.0.

To Reproduce

Create zeros.csv:

  id,x
  1,-0.0
  2,0.0

Run:

CREATE EXTERNAL TABLE zeros (
  id BIGINT, x DOUBLE
)
STORED AS CSV LOCATION 'zeros.csv'
OPTIONS ('has_header' 'true');

SELECT
  id,
  x = CAST(0 AS DOUBLE) AS eq,
  x IN (CAST(0 AS DOUBLE), CAST(5 AS DOUBLE)) AS in_list,
  x NOT IN (CAST(0 AS DOUBLE), CAST(5 AS DOUBLE)) AS not_in_list
FROM zeros
ORDER BY id;

Expected, and actual in 55.2.0:

id | eq   | in_list | not_in_list
1  | true | true    | false
2  | true | true    | false

Actual in 56.0.0-dev:

id | eq   | in_list | not_in_list
1  | true | false   | true
2  | true | true    | false

DF55 rewrites these short lists into equality/inequality chains. DF56 retains membership expressions, exposing signed-zero behavior inconsistent with equality. Both Float32 and Float64 are affected.

Expected behavior

No response

Additional context

Longer lists and constant folding already exhibit this inconsistency in 55.2.0:

  SELECT
      -CAST('0.0' AS DOUBLE) = CAST('0.0' AS DOUBLE) AS eq,
      -CAST('0.0' AS DOUBLE) IN (
          CAST('0.0' AS DOUBLE),
          CAST(5 AS DOUBLE),
          CAST(6 AS DOUBLE),
          CAST(7 AS DOUBLE)
      ) AS in_list;

Expected: (true, true)
Actual in both versions: (true, false)

Willingness to contribute

None