How does cbcopy handle a duplicate value conflict when the DISTRIBUTED BY column is also the PRIMARY KEY?

[asheraz048i2c]

Context:
I'm migrating a production database from Greenplum 7 to Apache Cloudberry 2.0.1 using cbcopy. One of the tables (~880 million rows) has its DISTRIBUTED BY column also defined as the PRIMARY KEY.
Question:
If the source table contains duplicate values in this column — for example due to a constraint that was disabled or marked NOT VALID at some point on the source side — what is cbcopy's actual behavior when loading into a target table where the PRIMARY KEY constraint is active?
Specifically:
Does cbcopy do any pre-check on this column before starting the load, or does it just attempt the insert and let the target's constraint layer catch it?
When a duplicate key violation happens mid-load, does the entire table/partition load abort and roll back, or does it skip the conflicting row(s) and continue with the rest?
Is there any flag or option to control this behavior — for example, skipping and logging conflicting rows versus a hard failure?
I'd like a definitive answer before running this on a table this large in production, rather than relying on trial-and-error. Any insight from someone who has hit this scenario during a large-scale migration would help a lot.
Environment:
Source: Greenplum 7.x
Target: Apache Cloudberry 2.0.1
Table size: ~880 million rows
Column: DISTRIBUTED BY + PRIMARY KEY (same column)