percentile_disc / percentile_cont: NULL in fractions array causes XX000 (MustBeDFloat)

When the fractions argument is an array containing NULL, both percentile_disc and percentile_cont hit an internal error instead of returning a user-facing result (PostgreSQL returns NULLs in the output array).

ERROR: internal error: expected *DFloat, found tree.dNull
SQLSTATE: XX000
Stack points at validateInputFractions → MustBeDFloat in pkg/sql/sem/builtins/aggregate_builtins.go.

Out-of-range fractions are already rejected cleanly; NULL is not guarded in the same helper (both aggregates share it).

To reproduce
SELECT percentile_disc(ARRAY[0.25::float8, NULL::float8])
WITHIN GROUP (ORDER BY x)
FROM (VALUES (1::float8),(2::float8),(3::float8)) v(x);
SELECT percentile_cont(ARRAY[0.25::float8, NULL::float8])
WITHIN GROUP (ORDER BY x)
FROM (VALUES (1::float8),(2::float8),(3::float8)) v(x);
Observed (CockroachDB v25.2.0): XX000 as above
Expected (PostgreSQL 18): {1,NULL} / {1.5,NULL}

Control (works): ARRAY[1.5::float8] → percentile value 1.500000 is not between 0 and 1

Environment
CockroachDB CCL v25.2.0 (built 2025/05/15)
Compared with PostgreSQL 18.4
Suggested fix
In validateInputFractions, check for NULL before MustBeDFloat (or skip/propagate NULL like PG), so both percentile_disc and percentile_cont get the same behavior.

Jira issue: CRDB-66908

Start in pkg/sql/sem/builtins/aggregate_builtins.go at validateInputFractions and inspect how percentile_disc and percentile_cont share it. Run the two SQL reproductions from the issue, then add coverage for NULL fractions and verify both return {1,NULL} and {1.5,NULL} instead of XX000 while out-of-range fractions remain rejected.

Written by the indexing model from the issue text.