Core Data: Replace mutated edits with original record to fix dirty state

[karthikeya-io]

What?

Closes #77610

This PR fixes the issue where the editor gets stuck in a dirty state ("Changes you made may not be saved" warning) after successfully restoring a visual revision or saving a post that contains meta updates (like when using the Footnotes block).

Why?

When saveEntityRecord prepares to send meta edits to the server, __unstablePrePersist() changes the edits.meta payload by injecting an internal collaborative editing key (_crdt_document).

After the save succeeds, saveEntityRecord dispatches receiveEntityRecords to clear the saved edits from the store. Previously, it passed the mutated edits variable as the persistedEdits argument.

Because the Redux reducer compares the original edits in the store (which lack _crdt_document) against this mutated persistedEdits object using fastDeepEqual, the comparison fails. The reducer incorrectly assumes the save was incomplete and leaves the post permanently "dirty".

How?

This PR updates saveEntityRecord to pass the original, un-mutated record to receiveEntityRecords as persistedEdits. This ensures the equality check succeeds and the editor correctly clears its dirty state.

Testing Instructions

Visual Revisions

1. Create a new post and publish it.
2. Make a change to the post to create a new revision, and click "Update".
3. Open the visual revisions interface and restore the previous revision.
4. Attempt to refresh the page or navigate away. You should no longer see the "Changes you made may not be saved" warning.

Test 2: Meta-updating Blocks

1. Open a post.
2. Add a Footnote block (which updates post meta).
3. Save the post.
4. Attempt to refresh the page or navigate away. You should no longer see the "Changes you made may not be saved" warning.

Screenshots or screencast

Before

• Please check the issue description (Restoring a revision using Visual Revisions or saving a post with meta blocks leaves the editor in a dirty state #77610 )

After

dirty_editor_state.mov

Use of AI Tools

• Yes, Used Gemini CLI to assist with debugging

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: karthikeya-io <karthikeya01@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Package] Core data.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[Mamaduka]

I think similar issue was fixed recently. See #77529. cc @alecgeatches

[Mamaduka]

Changing to record means that entityConfig.__unstablePrePersist never runs for this save, while it might fix the mentioned issue, it will break something else.

[karthikeya-io]

Thanks for checking this. I replaced edits with record in the 6th argument of receiveEntityRecords (which happens after the save). This argument seems to be used as persistedEdits to reset the user's edits from the store. So I think this shouldn't affect __unstablePrePersist or the data we save to the database.