different plan when set the enable_parallel on REPLICATED table.

### Apache Cloudberry version

_No response_

### What happened

```
drop table if exists with_test2 cascade;
drop table if exists with_test3 cascade;
create table with_test2 (id bigserial NOT NULL, isc varchar(15) NOT NULL,iscd varchar(15) NULL) DISTRIBUTED REPLICATED;
create table with_test3 (id numeric NULL, rc varchar(255) NULL,ri numeric NULL) DISTRIBUTED REPLICATED;
insert into with_test2 (isc,iscd) values ('CMN_BIN_YES', 'CMN_BIN_YES');
insert into with_test3 (id,rc,ri) values (113551,'CMN_BIN_YES',101991), (113552,'CMN_BIN_NO',101991), (113553,'CMN_BIN_ERR',101991), (113554,'CMN_BIN_NULL',101991);
explain
WITH
t1 AS (SELECT * FROM with_test2),
t2 AS (SELECT id, rc FROM with_test3 WHERE ri = 101991)
SELECT p.*FROM t1 p JOIN t2 r ON p.isc = r.rc JOIN t2 r1 ON p.iscd = r1.rc LIMIT 1;
```
The result when enable_parallel turn on and off.

This case has nothing to do with the table's statistics.
Result after analyze:

### What you think should happen instead

_No response_

### How to reproduce

pass

### Operating System

any

### Anything else

_No response_

### Are you willing to submit PR?

- [ ] Yes, I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/cloudberry/blob/main/CODE_OF_CONDUCT.md).

No source file or test entry point is named. Start by running the supplied SQL with enable_parallel both on and off, compare the EXPLAIN plans, and investigate the replicated-table planner path; done means the plan discrepancy has an agreed expected result and is resolved.

Written by the indexing model from the issue text.