fix: ensure unique IDs for new array rows in bulk updates

[imsidkg]

What?

This PR addresses a bug where bulk updating documents that include array fields with newly added rows would fail. Specifically:

• When attempting to add a new row to an array field (e.g., store_statuses in the Users collection) across multiple documents in a single bulk update operation:
  • The update would succeed for the first document.
  • The update would fail for subsequent documents.

---

Why?

The root cause was that Payload's bulk update operation reused the same temporary client-generated ID for new array rows across all documents being updated.

• When the first document’s array row was inserted, it used this temporary ID.
• On subsequent documents, trying to insert another row with the same ID triggered a unique constraint violation, causing the entire bulk update to fail.

---

How?

The fix is implemented within the updateOperation for collections:

1. Before the data for each document is passed to updateDocument, a deep copy of the data is made.
2. For any array fields within this copied data:
   • New rows (identified by their temporary string-based IDs) have their id property removed.
3. This ensures the database adapter generates fresh, unique IDs for each new array row in every document, preventing unique constraint violations.

---

Link to reproduction

https://github.com/JesperWe/bulk-update-array.git

Fixes #13736

Watch this

[r1tsuu]

The implementation doesn't look right to me. This isn't the place for transforming the data, usually you want to do this in our beforeValidate hook here https://github.com/payloadcms/payload/blob/c7795fa4a1fbc4f5892063b9e978d62dd6bb78a7/packages/payload/src/fields/hooks/beforeValidate/promise.ts or beforeChange could also work as well https://github.com/payloadcms/payload/blob/c7795fa4a1fbc4f5892063b9e978d62dd6bb78a7/packages/payload/src/fields/hooks/beforeChange/promise.ts, also it's not only about the place, but for example if your array field is nested to some another field - this wouldn't work.

2 - we definitely want an integration test here.