Windows pip wheel ships without third-party DLLs (libzmq, yaml-cpp) → load failure

[lukemartinlogan]

Repro

After PR #442 landed, the new Test Windows wheels CI job catches a real bug. v1.9.1-pre wheel installs cleanly but chimaera --help exits -1 with no output:

=== CLI test ===
chimaera --help died with exit code -1 (likely missing DLL or binary)

Failing run: 26356683592.

Root cause

The Windows wheel (iowarp_core-1.9.1-cp312-cp312-win_amd64.whl) contains only IOWarp-owned DLLs in iowarp_core/bin/. The vcpkg-provided third-party DLLs are missing:

$ objdump -p iowarp_core/bin/clio_run_cxx.dll | grep "DLL Name"
DLL Name: clio_ctp_host.dll          ← in wheel
DLL Name: yaml-cpp.dll               ← NOT in wheel
DLL Name: libzmq-mt-4_3_5.dll        ← NOT in wheel
DLL Name: WS2_32.dll                 ← system
...

When chimaera.exe launches, Windows resolves its import table via the standard search order (.exe's own dir, system32, PATH). It finds the IOWarp-owned DLLs co-located in bin/, but yaml-cpp.dll / libzmq-mt-4_3_5.dll aren't anywhere it looks, so the load fails before any code runs — hence exit -1 with no output.

The Python extension modules (.pyd in iowarp_core/ext/) appear to work because cte_available() only checks for the file's existence, not its loadability. Actually importing the .pyd would hit the same missing-DLL wall.

Why this snuck past v1.9.0

Prior to PR #442 there was no Windows wheel test in CI. Build Windows wheels succeeded (vcpkg deps were findable in the CI runner's vcpkg install dir during the link stage), but cibuildwheel did NOT run a repair step on Windows wheels — unlike delocate on macOS and the custom repair_wheel.sh on Linux, the Windows path skipped wheel-bundling entirely. The wheel shipped to PyPI with dangling DLL imports.

Fix

Add a CIBW_REPAIR_WHEEL_COMMAND_WINDOWS to the build-wheels-windows job in .github/workflows/build-pip.yml. cibuildwheel ships with delvewheel integration for Windows; we just need to enable it and point it at vcpkg's DLL directory.

CIBW_REPAIR_WHEEL_COMMAND_WINDOWS: >-
  delvewheel repair -w {dest_dir} -v {wheel}
  --add-path C:/vcpkg/installed/x64-windows/bin

delvewheel walks the wheel's PE imports, copies missing DLLs into iowarp_core.libs/ (or similar), and rewrites the import table to find them via os.add_dll_directory at import time.

Test plan

• PR CI: Test Windows wheels job now passes (chimaera --help returns 0, prints usage)
• On merge + v1.9.1 tag: the published Windows wheels each contain a .libs/ (or .dlls/) directory with libzmq*.dll, yaml-cpp.dll, libsodium*.dll, msgpack*.dll
• pip install iowarp-core==1.9.1 on a fresh Windows venv → chimaera --help runs

Scope

Just the Windows DLL bundling. The packaging workflow fix (DEB / RPM / AppImage) is tracked separately in #444 / PR #445.