Repair wp/6.5 branch Actions: Fix theme-activation navigation race in activate-theme.js - #83002

Part of #82928.

What?

Fixes a race condition in packages/e2e-test-utils/src/activate-theme.js's activateTheme() helper, responsible for all 19 tests in packages/e2e-tests/specs/editor/various/change-detection.test.js failing in CI with:

TimeoutError: waiting for selector `div[data-slug="twentytwentyone"].active` failed: timeout 30000ms exceeded

activateTheme() clicks the "Activate" link on wp-admin/themes.php, then immediately calls page.waitForSelector() (bare 30s Puppeteer default) to confirm the click took effect. The click itself is never wrapped in a page.waitForNavigation(). This PR wraps it in one, mirroring the existing, already-correct pattern already used by packages/e2e-test-utils/src/login-user.js, and gives the trailing waitForSelector() its own explicit 45s timeout.

Why?

WordPress core's "Activate" link (wp-admin/js/theme.js) is a plain, unhandled <a href> — clicking it triggers a real, full-page, server-driven navigation (switch_theme(), then a redirect back to themes.php), not a client-side/JS-intercepted action. Without an explicit page.waitForNavigation() around the click, the single, bare 30s waitForSelector() that follows has to cover the entire click → server switch_theme() → redirect → full admin-page reload chain by itself. That's a genuine race: a sibling e2e test file's identical activateTheme() call passed in the same CI run in which this one failed, and the shared beforeAll hook in config/setup-test-framework.js calls activateTheme( 'twentytwentyone' ) once per test file — so any file unlucky enough to hit a slow tail on that one click loses the race and fails outright.

login-user.js already solves the identical problem correctly for its own submit-button click:

await Promise.all( [
	page.click( '#wp-submit' ),
	page.waitForNavigation( { waitUntil: 'networkidle0' } ),
] );

This PR applies the same pattern to activateTheme()'s click, so the existing isCurrentURL()/fallback-revisit logic and the final waitForSelector() only ever run once navigation has genuinely finished. The trailing waitForSelector() also gets an explicit 45s timeout (up from Puppeteer's bare 30s default) — some headroom for the page's own post-navigation render tail (WordPress admin loading/parsing/rendering its JS bundles after the reload), without silently masking a real future regression by setting it unreasonably high.

The existing "theme has no activate button" branch (meaning the theme is already active) is untouched: it returns immediately after switchUserToTest(), before the click/navigation code is ever reached, so it's unaffected by this change and never triggers a navigation wait.

Use of AI Tools

This PR was created by Claude Code under my supervision. All code should be treated as AI-produced and not yet reviewed by a human until this PR is marked Ready for Review.