Repair wp/6.4 branch Actions: Retry Puppeteer plugin activation/deactivation on timeout - #83690

Part of #82929.

What?

Fixes Puppeteer end-to-end tests failing on timeouts in activatePlugin/deactivatePlugin (Puppeteer - 1, - 2 and - 3), in two steps:

1. Raises the wait after clicking "Activate"/"Deactivate" from Puppeteer's 30-second default to 60 seconds, since the plugins screen can take longer than that to render under CI load.
2. Retries the click-and-wait once if even the 60-second wait times out.

A 60-second wait alone isn't enough; for example, allowed-patterns.test.js's beforeAll hook still timed out calling activatePlugin( 'gutenberg-test-allowed-patterns' ):

TimeoutError: waiting for selector `tr[data-slug="gutenberg-test-allowed-patterns"] .deactivate a` failed: timeout 60000ms exceeded
    at ... activate-plugin.js:33:13
    at Object.<anonymous> (specs/editor/various/allowed-patterns.test.js:31:3)

Why?

Unlike an it()-level failure, a beforeAll/afterAll hook failure doesn't get a second chance from Jest's own jest.retryTimes(2) safety net (packages/e2e-tests/config/setup-test-framework.js) — that only re-runs test bodies, not hooks. So when the one-shot 60-second wait in activatePlugin/deactivatePlugin times out under CI resource contention, the entire describe block fails at once with no fallback, which is exactly what's observed (a single beforeAll timeout cascades into every it() in the file being reported as failed).

This PR wraps the click-and-wait sequence in both helpers in a bounded retry loop (2 attempts): on a timeout it re-visits plugins.php and tries again, rather than failing immediately. The retry first checks whether the previous attempt actually succeeded server-side and only the render wait timed out (in which case the "Activate"/"Deactivate" link is already gone), so it never tries to click a link that no longer exists.

The loop stops at 2 attempts because these helpers usually run in a hook, and Jest stops a hook after 100 seconds on this branch (jest.setTimeout( PUPPETEER_TIMEOUT || 100000 ) in setup-test-framework.js; CI does not set PUPPETEER_TIMEOUT). A first attempt that times out uses about 60 seconds, which leaves roughly 40 seconds for the second, so a third attempt would never start. That second attempt still covers the most common case: the plugin was activated or deactivated server-side and only the page was slow to render, which the reload shows right away.

Upstream

There is no trunk change to port. Trunk never changed these helpers; it moved its end-to-end tests from Puppeteer to Playwright instead (the allowed patterns tests in #57399) and later removed @wordpress/e2e-test-utils entirely in #72880. Playwright's requestUtils.activatePlugin() activates plugins through the REST API rather than the plugins screen, so it has no equivalent wait.

wp/6.5 and newer have no Puppeteer tests that call these helpers. wp/6.3 and older have the same helpers, but none of their recent CI runs hit this timeout.

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.