CI: modernize composer/checkout actions, harden test workflows, fix core cron REQUEST_URI notice

[remyperona]

Description

Fixes n/a

Modernizes the PHP test and deploy GitHub Actions workflows and clears the warnings they currently emit. No plugin runtime code is changed — the only non-workflow edit is a test-bootstrap default.

• Bump actions/checkout to v7 (Node 24) across the PHP test workflows and deploy_plugin.
• Replace the custom "get composer cache dir + actions/cache + composer install" boilerplate with ramsey/composer-install@v4 (wraps actions/cache@v5 on Node 24), keeping --no-scripts so Mozart / dump-autoload / text-domain scripts stay disabled in CI. This removes both the deprecated set-output command and the Node 20 action warnings.
• Guard $_SERVER['REQUEST_URI'] on the shutdown hook in the integration bootstrap. Since WordPress 6.9, core's _wp_cron() runs on shutdown (wp-includes/cron.php) and reads $_SERVER['REQUEST_URI'] unguarded when spawning due cron events; under the PHPUnit CLI there is no request, so it emitted an "Undefined array key REQUEST_URI" notice at process shutdown.
• Harden the test workflows: add a concurrency group (matching the lint workflows), declare least-privilege permissions: contents: read, set fail-fast: false so one matrix leg no longer cancels the others, and add timeout-minutes: 30.

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Chore
• Release

Detailed scenario

What was tested

This PR's own GitHub Actions runs, verifying: (1) no Node 20 or set-output deprecation warnings remain in the PHP test workflows, (2) Composer dependencies install via ramsey/composer-install with --no-scripts (Mozart not re-run), and (3) the "Undefined array key REQUEST_URI" notice no longer appears at the start of the Cloudflare integration group.

How to test

Open this PR's Actions tab and inspect the four PHP test workflow runs — confirm they are green, the deprecation annotations are gone, and the Cloudflare integration group log no longer contains the REQUEST_URI warning.

Affected Features & Quality Assurance Scope

CI/tooling only. No plugin runtime behavior changes. The single non-workflow change is a test-only default for $_SERVER['REQUEST_URI'] in tests/Integration/bootstrap.php.

Technical description

The composer cache directory step used the deprecated ::set-output command and the cache/checkout steps ran on the retiring Node 20 runtime. ramsey/composer-install@v4 replaces the three-step pattern with a single maintained action (Node 24 via actions/cache@v5); --no-scripts preserves the current behavior of not re-running Mozart in CI. With composer.lock gitignored, the action's default locked mode resolves like the previous composer install.

The REQUEST_URI notice originates in WordPress core (wp-includes/cron.php, _wp_cron()), not in the plugin — all first-party reads are already guarded. WordPress 6.9 moved _wp_cron() to the shutdown action (default priority 10). Seeding the value at the top of the bootstrap did not survive the WP test suite's own $_SERVER setup, so the fix registers a shutdown callback at priority 0 (ahead of _wp_cron) that ensures the key exists just before core reads it. Test-only and production-safe.

Documentation

n/a

New dependencies

ramsey/composer-install GitHub Action (CI only; not a plugin/runtime dependency).

Risks

CI/tooling-only change. Worst case is a workflow misconfiguration, which surfaces immediately in this PR's own runs rather than affecting the shipped plugin.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

Built-in tests are not applicable: the change is GitHub Actions workflow configuration plus a test-only bootstrap default. The workflows are exercised directly by this PR's own CI runs.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Coverage ∅ diff coverage · +0.00% coverage variation

Metric	Results
Coverage variation	✅ +0.00% coverage variation (-0.10%)
Diff coverage	✅ ∅ diff coverage (50.00%)

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (3fb7260)	46709	22513	48.20%
Head commit (cde73df)	46709 (+0)	22513 (+0)	48.20% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#8691)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}