Vector functions overflow or underflow for finite Float64 inputs

[aoto-tech]

Describe the bug

I found that array_distance, cosine_distance, and array_normalize directly sum squared Float64 values. The intermediate squares can overflow or underflow even when the correct result is representable.

This can turn nonzero distances into zero, identical vectors into NaN, and valid normalized vectors into zero vectors.

To Reproduce

Tested on 55.1.0 and main at 9082d6b10.

SELECT array_distance([CAST(1e-200 AS DOUBLE)], [CAST(0 AS DOUBLE)]);
-- actual: 0.0; expected: 1e-200

SELECT cosine_distance(
  [CAST(3e200 AS DOUBLE), CAST(4e200 AS DOUBLE)],
  [CAST(3e200 AS DOUBLE), CAST(4e200 AS DOUBLE)]
);
-- actual: NaN; expected: 0.0

SELECT array_normalize([CAST(3e200 AS DOUBLE), CAST(4e200 AS DOUBLE)]);
-- actual: [0.0, 0.0]; expected: [0.6, 0.8]

Expected behavior

Finite inputs should not produce zero, NaN, or a zero vector when the mathematical result is finite and representable.

Additional context

The same unscaled sum-of-squares pattern appears in array_distance, cosine_distance, and array_normalize. I couldn't find an existing issue for this behavior.

[aoto-tech]

cosine_distance is particularly tricky.

• array_distance: Relatively straightforward. Scale the differences by their maximum absolute value before computing the sum of squares.
• array_normalize: Similar—divide by the largest absolute component before calculating the norm.
• cosine_distance: More difficult because not only the norms but also the a * b terms in the dot product can overflow. The implementation also needs to handle cancellation between positive and negative values, zero vectors, and the semantics of NaN and Infinity.

[namanjain24-sudo]

take