Copy Locale Data breaks documents on Postgres when drafts are enabled and localized array/blocks rows exist (duplicate key pkey on the row id)

Describe the Bug

On Postgres with versions.drafts enabled, clicking Copy Locale Data on a document whose localized array/blocks fields already have rows in the source locale fails with

ERROR: duplicate key value violates unique constraint "<table>_pkey"
DETAIL: Key (id)=(<the SOURCE locale's live row id>) already exists.

and the admin surfaces the misleading field error "The following field is invalid: id". After the failed attempt, subsequent saves of the document can keep failing the same way (the stale ids stay in the open form), effectively bricking the document for editors.

We measured the full chain on 3.88.0 (each link verified in isolation, probes below):

1. The target-locale fetch falls back to the source locale. copyDataFromLocale fetches the target locale without fallbackLocale: false (packages/ui/src/utilities/copyDataFromLocale.ts — the payload.findByID({ locale: toLocale, draft: true, … }) call). With an empty target locale, Payload's locale fallback returns the source locale's data — including all array/blocks row ids and _status: 'published'. As a side effect, the "target is empty" merge branch can never fire for documents that have source data.
2. removeIdIfParentIsLocalized then strips all row ids below localized fields, and the handler calls payload.update({ data, draft: true, locale: toLocale }) — with the merged data still carrying _status: 'published' from step 1.
3. draft: true combined with incoming _status: 'published' rewrites the LIVE rows of BOTH locales — and the write re-inserts the source locale's rows without deleting them first. Because the generated row tables use a single-column id primary key (not composite (id, _locale) — same anatomy as #16054), the second insert collides with the source locale's still-live row id.

Isolation probes (all on 3.88.0, Postgres 16, drafts + autosave enabled)

So the failure is not the id copying per se: it is the draft: true update whose data still carries _status: 'published', fed by the fallback fetch. Collection-level hooks cannot heal it — the colliding row comes from the internal live-row rewrite, not from data.

Why the existing tests don't catch it

The copy-locale integration tests run against fixtures with versions: false — the drafts + localized-rows + Postgres combination is untested.

To Reproduce

1. Postgres adapter, a collection with versions: { drafts: { autosave: true } }, two locales (de default, en), and a localized blocks field containing a block with a nested array field.
2. Create a document in de, add a block with one array row, publish it.
3. Switch the admin to en (empty locale) and use Copy Locale Data (de → en).
4. The update fails with the pkey violation above; the admin shows "The following field is invalid: id".

Suggested fix (happy to open a PR)

Two independent, small changes in copyDataFromLocale:

1. Fetch both locales with fallbackLocale: false — the target fetch must reflect what the target locale actually contains, otherwise the empty-target merge branch is dead code and the source's _status leaks into the update.
2. Strip _status (and createdAt/updatedAt) from the merged data before the draft: true update — copying a locale should produce a draft of the target locale, never an implicit publish that rewrites both locales' live rows.

We have a fork/branch prepared (fix/copy-locale-fresh-row-ids-3x off 3.x) and can turn this into a PR with an integration test (drafts-enabled fixture) if the direction is agreed.

Environment

• Payload: 3.88.0 (@payloadcms/db-postgres, @payloadcms/richtext-lexical)
• Database: PostgreSQL 16
• Next.js 16.2.12, Node 24.x
• Related: #16054 (single-column pkey on localized array rows — same underlying anatomy)