External Libraries: Update jQuery Migrate to 3.6.0

[rootzero00]

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

Summary

Update the bundled jQuery Migrate library from 3.4.1 to 3.6.0 while keeping jQuery Core at 3.7.1.

The change updates:

• src/js/_enqueues/vendor/jquery/jquery-migrate.js
• src/js/_enqueues/vendor/jquery/jquery-migrate.min.js
• the registered jQuery Migrate version in src/wp-includes/script-loader.php

Validation

The candidate was validated against current WordPress runk.

Completed validation included:

• WordPress JavaScript build and pre-commit-equivalent checks
• TypeScript and compiled QUnit checks
• PHPCS and PHPCBF no-op verification
• PHPStan
• the full seven-target PHPUnit matrix
• frontend and admin runtime checks
• runtime verification of jQuery 3.7.1 and jQuery Migrate 3.6.0
• verification that jQuery loads before jQuery Migrate
• development Migrate warning capture and separation from JavaScript runtime errors
• final refresh and revalidation against current runk

No unresolved candidate-attributable regression was found.

AI assistance

AI assistance was used during investigation, validation design, and preparation of this contribution. All resulting changes were reviewed and validated by the contributor.

---

This pull request is for code review against the existing WordPress Core Trac ticket. It is not intended to be merged directly on GitHub.

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

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.

[rootzero00]

The refreshed branch is based on current WordPress trunk at:

56ae1c9

Current validation state for this exact head:

• 135 successful checks
• 0 failing checks
• 0 pending checks
• 1 cancelled check: PHP 8.5 / MySQL 8.0

Cancelled workflow run: 33470652096
Cancelled job: 99739640082

I performed a read-only comparison against the exact trunk base of this PR:

• Exact base: 049287a
• The PR is exactly 1 commit ahead and 0 commits behind that base.
• Exact-base trunk run 33452993781, job 99691240899, completed successfully in 807 seconds.
• Its main PHPUnit suite completed 31,044 / 31,044 tests in 533.7 seconds.
• The PR job ran for 1,215 seconds and was cancelled by the configured approximately 20-minute job ceiling.
• Its PHPUnit step lasted 952 seconds; the last logged progress was 21,063 / 31,044 tests (67%) after 950.3 seconds.
• Observed main-suite throughput was 22.16 tests/second on the PR runner versus 58.17 tests/second on the exact-base trunk runner.
• The slowdown was visible from the early progress checkpoints, rather than beginning at one identifiable test.
• Both jobs used runner version 2.337.0 and Ubuntu image release ubuntu24/20260823.283, but used different GitHub-hosted runner instances.
• No PHPUnit FAILURES!, ERRORS!, assertion failure, or test-error exit was reported before cancellation.

This evidence suggests an abnormally slow runner execution rather than an established contribution defect. No code change is being proposed in response.

I do not have permission on WordPress/wordpress-develop to rerun Actions jobs. Could a maintainer please rerun the cancelled PHPUnit workflow when convenient?