Editor: Run autoembed() before do_blocks() in block content filters

[i-am-chitti]

Description

_wp_apply_block_content_filters() called WP_Embed::autoembed() after do_blocks(), so it ran over rendered block output instead of the source. the_content (autoembed at 8, do_blocks() at 9), get_the_block_template_html() and render_block_core_block() all autoembed the source only. This moves the call before do_blocks() to match.

render_block_core_pattern() has the same ordering problem and is the path behind the symptom reported in the ticket, but that file is synced from Gutenberg by tools/gutenberg/copy.js, so it is handled separately in GUTENBERG_PR_URL. This PR alone does not fix the reported bug — it aligns the one code path core owns.

Trac ticket: https://core.trac.wordpress.org/ticket/66077

Testing instructions

npm run test:php -- --filter Tests_Blocks_WpApplyBlockContentFilters

test_autoembed_runs_before_do_blocks fails before the change and passes after. It asserts a URL present only in a nested block's rendered output is no longer turned into an embed, while test_applies_content_filters continues to assert a URL in the source still is.

AI usage

• Model: Claude Opus 5
• Used for: root cause analysis, the patch, and the unit tests.

[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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props iamchitti.

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

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[talldan]

I think there should be another @since 7.x.x comment here documenting the change.

For example:
https://github.com/i-am-chitti/wordpress-develop/blob/87f824ba025a25f2fb191c9dc8292bb47cb8e4f9/src/wp-includes/blocks.php#L503-L510

However we need to know which version this will ship in. I think we may consider shipping it in a 7.1.x release (probably 7.1.2 as I think it's late for 7.1.1, I'm not really up to date with the timeline of that release, maybe it already happened). That might be an idea because the function was only introduced in 7.1.0.

Alternatively it could go into 7.2. Lets discuss on the trac ticket.

[talldan]

The change looks good to me. I tested it and it works well. The reasoning is sound. I mentioned a little bit more in the gutenberg ticket.

I added one comment, but we'll have to figure out which version the PR/ticket is targeting to address it. The ticket is unmilestoned.