ci: fix only the Windows PHP download URL

[armando-rodriguez-cko]

What

Reverts both workflow files to exactly what they were before #362, then changes one thing: the two Windows PHP download URLs.

Net diff against the pre-#362 state is four lines, two of which are a comment.

Why

downloads.php.net/~windows/releases/ keeps only the current patch of each branch. When 8.4.24 shipped, the pinned php-8.4.23-Win32-vs17-x64.zip link began returning 404 and build-master died during setup, before running a test:

Invoke-WebRequest : The remote server returned an error: (404) Not Found.

The archive at windows.php.net/downloads/releases/archives/ keeps every patch, so the URLs no longer rot. Both verified to return the file.

What is deliberately NOT here

Everything else #362 introduced is reverted: the workflow_call trigger, build-pull-request.yml as a caller, the checksum verification, the release-guard change. Two independent workflow files with their original triggers, guards and steps.

That is the point of this PR: the smallest possible change to stop CI failing, and nothing else.

Known review noise

SonarCloud may flag composer update and the unverified download on the restored lines, because reverting a file makes its lines count as new code. Both are byte-identical to what has been on master for months, where they are not flagged. Accepted deliberately rather than fixed here.

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-master.yml
• security_sensitive_path:.github/workflows/build-pull-request.yml

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 2

---

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-master.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-pull-request.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🟠 Advisory review: Concerns worth a look

This PR needs a human approval. Before you give it, these are the things I'd want resolved.

This PR fixes the 404 Windows PHP download URL by switching to the archive path, but in doing so it also restores the pre-#362 state including: piping curl directly into php for Composer install (removing signature verification), removing SHA-256 checksum verification for the PHP zip, and reverting build-pull-request.yml to ubuntu-only (no Windows matrix on PRs), which was the original drift vector that allowed the URL bug to sit undetected.

Concerns

• build-master.yml line ~57: Restores curl -sS https://getcomposer.org/installer | php — this executes whatever the network returns with no integrity check, which the previous version deliberately fixed; this is a security regression on a job that runs with repository secrets.
• build-master.yml Windows setup block: SHA-256 checksum verification of the PHP zip is removed, so a corrupted or substituted archive will be silently unzipped and executed.
• build-pull-request.yml: PRs now run ubuntu-only again (matrix has only ubuntu-latest), meaning a Windows-specific break can sit undetected until it hits master — this is explicitly the condition the PR description says caused the original problem.
• The actual fix (archive URL for 8.4) is correct and the 8.1 archive URL is unchanged, but the 8.4 URL is still pinned to 8.4.23; if the intent is 'URLs that don't rot', they do not rot at the archive path, so this part is fine.
• The if guard in build-master.yml is restored to !contains(github.event.commits[0].message, 'Release') without the github.event_name != 'push' guard — on a workflow_call (if that trigger is ever re-added) or any non-push event this expression evaluates against nothing, which was the exact problem the removed comment described.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[sonarqubecloud]

Quality Gate failed

Failed conditions
E Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE