`percentile_cont` truncates Float64 interpolation weights to six decimal places

[aoto-tech]

Describe the bug

I found that percentile_cont quantizes its Float64 interpolation weight in steps of 1e-6. Small nonzero weights therefore become zero, producing the lower input value instead of an interpolated result.

To Reproduce

I reproduced this on 55.1.0 and main at 9082d6b10.

SELECT percentile_cont(x, CAST(2.5e-7 AS DOUBLE))
FROM (VALUES
  (CAST(0.0 AS DOUBLE)),
  (CAST(1.0 AS DOUBLE)),
  (CAST(2.0 AS DOUBLE))
) AS t(x);

actual:   0.0
expected: 5e-7

### Expected behavior

The rank is `(3 - 1) * 2.5e-7 = 5e-7`, so linear interpolation between `0.0` and `1.0` should return approximately `5e-7`.

### Additional context

The Float64 path converts the fraction to an integer using [`INTERPOLATION_PRECISION = 1_000_000`](https://github.com/apache/datafusion/blob/9082d6b10c29b72d56bede3d8e353d9d61fde542/datafusion/functions-aggregate/src/percentile_cont.rs#L935-L945). That truncates this weight to zero. I couldn't find an existing issue for the Float64 behavior.

[aoto-tech]

Using the original fraction directly should basically fix it, though the testing may be fairly involved.

[aoto-tech]

/take