Notes: Arm the mention kses allowance on REST note creation

[adamsilverstein]

What?

Fixes #80258. Follow-up to #79604. Arms the note mention kses allowance when a note is created through the REST API, so the <a class="wp-note-mention user-N"> markup survives saving for users without unfiltered_html.

Why?

The mention kses scoping added in #79604 never fires on the REST create path:

• WP_REST_Comments_Controller::create_item() only copies the type param into the prepared data after prepare_item_for_database() has applied rest_preprocess_comment, so gutenberg_notes_scope_mention_kses_rest() sees no comment type (and no id to resolve one from) and does not arm.
• create_item() then inserts through wp_insert_comment( wp_filter_comment( ... ) ) directly, never calling wp_new_comment(), so the preprocess_comment arm does not fire either.

As a result, creating a note with a mention as an author or contributor (or as anyone but a super admin on multisite) silently strips the mention classes, which breaks mention chips in the UI and, once #79606 lands, mention notifications.

How?

When the prepared data and the request id leave the comment type unknown, resolve it from the request's type param, which create_item() validates against core types before preparing.

Testing Instructions

1. As a user without unfiltered_html (e.g. an author) on a post they can edit, open the editor and add a note that @-mentions another user.
2. Save and reload: without this fix the mention renders as a plain link (classes stripped); with it the mention chip survives.

Regression tests: test_rest_prepare_arms_for_note_creation, test_rest_prepare_does_not_arm_for_regular_comment_creation, and test_mention_markup_survives_rest_note_creation_end_to_end fail without the fix and pass with it:

npm run test:unit:php:base -- --filter Tests_Notes_Mention_Kses

[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: adamsilverstein <adamsilverstein@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]

Flaky tests detected in ce2f51e.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29354680864
📝 Reported issues:

• [Flaky Test] adds and activates a new tab when pressing Enter at the end of a tab label #80106 in /test/e2e/specs/editor/blocks/tabs.spec.js

[Mamaduka]

Makes sense. Thanks, @adamsilverstein!

[adamsilverstein]

@t-hamano I'm not sure about the labeling here, there is no JS to backport, I am backporting the PHP part in a core PR.

[t-hamano]

I'm not sure about the labeling here, there is no JS to backport, I am backporting the PHP part in a core PR.

Just in case, it would be better to backport this PR to 7.1. This is to ensure that upcoming Gutenberg 23.6 includes equivalent bug fixes to 7.1, and to reduce the possibility of conflicts when backporting other PRs that depend on this PR in the future.

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 1e2ccca230b1066fbbab364a7f6d6ad504d03c73

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[t-hamano]

The bot comment was not added for some reason, but this PR has already been backported to wp/7.1.

b843a8e

[t-hamano]

I just cherry-picked this PR to the release/23.6 branch to get it included in the next release: eac55b7