Windows CI: flaky pcre2/zlib/openssl tarball download in test_new.yml's build-windows job

Summary

The build-windows job in .github/workflows/test_new.yml's "Set up third-party libraries" step intermittently fails downloading pcre2/zlib/openssl for the nginx build itself:

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now

from:

wget -q -O - https://github.com/PCRE2Project/pcre2/releases/download/pcre2-10.47/pcre2-10.47.tar.gz | tar -xzf -
wget -q -O - https://www.zlib.net/fossils/zlib-1.3.2.tar.gz | tar -xzf -
wget -q -O - https://www.openssl.org/source/openssl-3.6.2.tar.gz | tar -xzf -

The -q flag on wget also hides which of the three downloads actually failed, and piping straight into tar with no retry means a single truncated/interrupted download kills the whole job immediately with no diagnostic output about the download itself.

Impact

Intermittent, not deterministic (unlike the separate, unrelated yajl/CMake issue also affecting this same job — see owasp-modsecurity/ModSecurity#3604) — a re-run of the same job sometimes gets past this step and sometimes doesn't, consistent with a flaky network fetch rather than a real incompatibility.

Suggested fix

• Add --retry-connrefused --tries=3 (or similar) to each wget call, or switch to curl --retry 3 --retry-delay 2 -fsSL.
• Drop the -q/-s quiet flag, or at least fail loudly with the HTTP status/URL on error, so a future failure here is immediately distinguishable from a build-step failure.
• Consider downloading once and caching the three tarballs (e.g. actions/cache) across matrix runs, since all three windows-nginx-* jobs in the matrix currently re-download the same fixed versions independently.

Where observed

build-windows job, e.g. https://github.com/owasp-modsecurity/ModSecurity-nginx/actions/runs/30317326448/job/90145603796 (triggered from PR #385, but unrelated to that PR's changes).

Start in .github/workflows/test_new.yml at the build-windows job's “Set up third-party libraries” step and review the referenced failed run logs. Confirm the three tarball downloads provide retry and useful failure diagnostics, then verify the step succeeds reliably on reruns without hiding which URL failed.