Improve zlib Windows library detection for future zlib versions

[hmennen90]

Summary

Builds on #1066 with three improvements to the zlib Windows library detection:

• Add libz.lib candidate — zlib 1.3.3+ may produce this name, which the current detection list misses
• Throw on missing library — if none of the known static library names are found, throw a clear RuntimeException instead of silently continuing with a broken build state
• Safe shared-lib cleanup — avoid accidentally deleting the detected static library during cleanup, and look for DLLs in bin/ where cmake actually puts them

We hit this in our fork when building with newer zlib versions on Windows and the build silently failed because the copy target didn't exist.

Changes

• src/SPC/builder/windows/library/zlib.php
  • Added libz.lib to detect list
  • Track which candidate was found, throw if none
  • Skip deletion of found static lib during cleanup
  • Clean DLLs from BUILD_ROOT_PATH/bin/ consistently

[hmennen90]

The CI failures are unrelated to this PR — all three Windows jobs fail with:

library [libaom] is in the lib.json list but not supported to compile

This appears to be a pre-existing issue in the test workflow configuration where libaom is included in the Windows build matrix but has no Windows library builder. The same failure would occur on any PR targeting main right now.

[hmennen90]

CI Status Update

The Windows CI jobs now progress significantly further than before this PR — builds run for ~9 minutes (compiling all libraries successfully) instead of failing immediately at startup.

What this PR fixes

1. zlib: Extended library detection for newer versions (1.3.3+ produces libz.lib)
2. libaom: Added missing Windows builder (was causing immediate library [libaom] is in the lib.json list but not supported to compile failure)
3. brotli: Added missing Windows builder (same issue, surfaced after libaom was fixed)

All three libraries now compile and install successfully on Windows.

Remaining CI failure (pre-existing, unrelated)

The builds now fail at the final PHP linking stage with unresolved symbols:

libfreetype_a.lib(sfnt.obj) : error LNK2001: unresolved external symbol BrotliDecoderDecompress
libfreetype_a.lib(ftbzip2.obj) : error LNK2001: unresolved external symbol BZ2_bzDecompressInit
libfreetype_a.lib(ftbzip2.obj) : error LNK2001: unresolved external symbol BZ2_bzDecompress
libfreetype_a.lib(ftbzip2.obj) : error LNK2001: unresolved external symbol BZ2_bzDecompressEnd

The linker command includes:

zlib_a.lib libjpeg_a.lib libpng_a.lib libfreetype_a.lib libiconv_a.lib libwebp.lib libsharpyuv.lib avif.lib

But is missing transitive dependencies: brotlicommon.lib, brotlidec.lib, brotlienc.lib, libbz2_a.lib, and aom.lib.

This is a separate issue in the extension/library dependency resolution for Windows — freetype is built with brotli and bzip2 support, but the PHP link step doesn't pull in those transitive static libraries. Similarly, avif.lib needs aom.lib at link time.

This would need to be addressed in the extension configuration (config/ext.json or the Windows builder's library linking logic) and is outside the scope of this PR.

[henderkes]

Remove the unrelated changes please. And I don't understand why the zlib diff is so large.

[henderkes]

what is this? you check for found === null earlier.

[henderkes]

BUILD_BIN_PATH

[henderkes]

the loop made it longer than it was before

[hmennen90]

Done — stripped down to a single-line change (just adding libz.lib to the detection list). The libaom and brotli Windows builders have been moved to a separate PR: #1072.