Fix two crashes/wrong-answer bugs in the gp_percentile_* transition functions (in REL_2_STABLE)

[Alena0704]

gp_percentile_cont() / gp_percentile_disc() are the split ordered-set
aggregates ORCA rewrites percentile_cont(), percentile_disc() and median()
into. Two bugs in their transition functions. Only the ORCA path reaches
these aggregates on its own, so percentile_* WITHIN GROUP on the Postgres
planner is unaffected.

1. Direct SQL calls read past the end of the argument array (2f409c8)

The transition functions read five arguments in C (state + the four
aggregate arguments), but pg_proc.dat declares four. As transition
functions they are called correctly; a direct SQL call makes
PG_GETARG_INT64(4) pick up garbage — wrong results, an assertion on
pfree(NULL), or a segfault.

Fixing the declaration would force an initdb, which is not acceptable on a
stable branch, so the argument count is checked and a plain error is
raised. Direct calls were never useful.

2. The isnull flag is lost when the previous state is returned (8251c47)

When the current row isn't one the percentile is computed from, the
previous state is handed back untouched. On the first call that state is
NULL, and returning a bare Datum(0) with isnull false drops the flag: 0
instead of NULL for by-value types, a NULL pointer dereference for
by-reference ones — an empty input set crashed the backend for interval,
timestamp and timestamptz.

Both ported from Greengage 477b04a (ADBDEV-7770)

The bug reproduction:

-- Bug 1: pg_proc.dat declares four arguments, the code reads five
select gp_percentile_disc_transition(NULL::numeric, 1, 1, 1);
-- before: server closed the connection unexpectedly
-- after:  ERROR:  wrong number of arguments to gp_percentile_disc_transition()
--         HINT:  expected 5, got 4

-- Bug 2, by-value: silently wrong answer
select gp_percentile_cont(0::float8, 0, 0, 0);             -- 0, expecting NULL
-- Bug 2, by-reference: backend crash
select gp_percentile_cont('0 hour'::interval, 0, 0, 0);    -- server closed the connection
-- Bug 2, the 6c289ad regression: a selected value whose Datum is 0 turns into NULL
select gp_percentile_disc(0::float8, 0, 1, 1);             -- NULL, expecting 0
select gp_percentile_disc(0::int,    0, 1, 1);             -- NULL, expecting 0

-- The same, end to end: ORCA and the Postgres planner disagree
create table perczero (a int, b float8) distributed by (a);
insert into perczero select i, (i - 1)::float8 from generate_series(1, 10) i;
select percentile_disc(0) within group (order by b) from perczero;  -- NULL
set optimizer = off;
select percentile_disc(0) within group (order by b) from perczero;  -- 0

Type of Change

• Bug fix (non-breaking change)
• New feature (non-breaking change)
• Breaking change (fix or feature with breaking changes)
• Documentation update

Breaking Changes

Test Plan

• Unit tests added/updated
• Integration tests added/updated
• Passed make installcheck
• Passed make -C src/test installcheck-cbdb-parallel

Impact

Performance:

User-facing changes:

Dependencies:

Checklist

• Followed contribution guide
• Added/updated documentation
• Reviewed code for security implications
• This PR contains AI-assisted code generation
• Requested review from cloudberry committers

Additional Context

CI Skip Instructions

---

[leborchuk]

LGTM, we should just fix it )

[Alena0704]

Fixed commit messages a bit.