ci(windows): mirror gettext-win over HTTP instead of cloning it

[luthermonson]

Every php-sdk Windows build has failed at the same line since roughly 2026-08-05 (the last shipped Windows asset):

[22/30] Downloading artifact gettext-win source from git ...
##[error]The action 'Download PHP sources' has timed out after 15 minutes.

Root cause

spc's gettext-win artifact (config/pkg/lib/gettext-win.yml in the fork, rc19):

source:
  type: git
  url: 'https://github.com/winlibs/gettext.git'
  rev: '0.18'

That is an unshallowed 57 MB clone — 5x its libiconv-win sibling. It stalls mid-packfile, and spc's git invocation carries -c http.lowSpeedLimit=1 -c http.lowSpeedTime=3600, so a 1 byte/sec trickle is tolerated for a full hour instead of failing. The 15-minute step budget always fires first.

It is not a block and not a bandwidth problem. Measured on the fleet node that actually runs these jobs (2026-09-18):

probe	result
git ref advertisement (info/refs)	HTTP 200 in 0.31s
winlibs/gettext tarball (29 MB)	4.2s @ 6.9 MB/s
libiconv-win tarball (5 MB, control)	1.2s @ 4.3 MB/s

The identical content arrives over HTTP in four seconds while the clone hangs past four minutes.

Note PR #64 did not cause this — it converted a silent 2-hour burn into a fast, visible failure, which is what made it diagnosable.

The fix

Fetch the tarball and hand it to spc via --custom-url.

This is sound for a type: git artifact: --custom-url replaces the artifact's source callback outright with a plain Url download (ArtifactDownloader::applyCustomDownloads), so spc never needs a .git tree. The codeload tarball carries a single top-level gettext-0.18/ dir which spc's extractor strips ("Unzip file with stripping top-level directory", ArtifactExtractor), landing the same layout the clone produced.

Downloaded to a file rather than passing the codeload URL directly, because spc names the archive basename($url) and the codeload path ends in /0.18 — extensionless, which breaks archive detection.

Soft-fails: if the mirror download fails, we warn and let spc attempt the clone. No worse than today.

Verification done before pushing

• PowerShell AST parse of the modified step: clean, no syntax errors
• The block, run verbatim from the file, emits --custom-url=gettext-win:file:///C:/.../gettext-win.tar.gz
• curl reads that file:// URL back at the full 29,157,062 bytes
• spc's explode(':', $v, 2) splits it to (gettext-win, file:///C:/...) — the drive-letter colon survives
• Tarball content confirmed to contain the declared libintl_a.lib at MSVC11/libintl_static/x64/Release/

Not yet verified by a real Windows build — that happens when this runs in CI.

Scope

libiconv-win is the same type: git shape and the same latent risk, but it downloads fine today, so it is deliberately left alone rather than churning a working path.

[ephpm]

ePHPm Preview — removed

Preview deployment has been torn down.

[luthermonson]

Validation build 35422511159 (windows-x86_64, release_tag_suffix=-gettextmirror) confirms the fix on real hardware:

05:20:22  ==> mirrored gettext-win as C:\actions-runner\_work\_temp\deps\gettext-win.tar.gz

Download PHP sources: 05:20:16 -> 05:22:08, success (1m52s) — the mirror landed ~6s into the step. This is the step that had failed at the 15-minute timeout on every Windows build since ~2026-08-05.

The run as a whole did not produce an artifact, but for an unrelated reason that this PR does not touch and was previously masked by the gettext hang: the build then stalled in OpenSSL.

05:46:30  perl.exe ...   (jom.exe /j8 install_dev)
          <- 1h24m of total silence ->
07:10:23  ##[error]The operation was canceled.   (timeout-minutes: 119)

The node was healthy throughout (135 GB disk free, 22 GB RAM free, no ephemerd error; ephemerd only tore the runner down after GitHub timed the job out). That stall is a separate bug and gets its own investigation.

Merging this on its own merits: it fixes the download step it targets, it is proven on hardware, and it soft-fails to the old behaviour if the mirror download ever fails.