percentile_cont(DISTINCT ...) panics on every query, and returns wrong results in sliding windows #23912

Describe the bug

DistinctPercentileContAccumulator has two bugs, both stemming from reusing the shared set-based GenericDistinctBuffer for an aggregate it doesn't fit:

1. Panic on every percentile_cont(DISTINCT ...) query. update_batch forwards all argument columns to GenericDistinctBuffer::update_batch, which asserts a single input array. percentile_cont always passes two columns (the value and the percentile literal), so any distinct query panics. This path has no existing test coverage, which is why it went unnoticed.

2. Wrong results in sliding windows. The buffer is a plain HashSet with no per-value multiplicity, so retract_batch drops a value entirely when one occurrence leaves the window frame, even when other rows in the frame still carry that value.

To Reproduce

CREATE TABLE t(id INT, x DOUBLE) AS VALUES (1,5),(2,5),(3,9);

-- Bug 1: panics with
-- "DistinctValuesBuffer::update_batch expects only a single input array (left: 2, right: 1)"
SELECT percentile_cont(DISTINCT x, 0.5) FROM t;

-- Bug 2 (once Bug 1 is fixed): sliding window drops the still-present duplicate 5
SELECT id, percentile_cont(DISTINCT x, 0.5)
  OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND CURRENT ROW)
FROM t ORDER BY id;

Expected behavior

• Query 1: 7 (median of distinct {5, 9}).
• Query 2: 5, 5, 7 — at row 3 the frame is {5, 9} (the row-2 5 is still in-window), so the distinct set is {5, 9}, median 7.

Actual behavior

• Query 1: panic.
• Query 2 (with Bug 1 worked around): row 3 returns 9 — retract dropped 5 entirely when the row-1 5 left, even though row-2's 5 remained.

Additional context

Confirmed by running: unfixed code panics on query 1; with the fix, both queries return the expected results and the full aggregate.slt suite passes.