[transfix]

On Windows the cvcpkg ImageMagick is extracted, not installed, so it has no registry entry. libcvc points MAGICK_CODER_MODULE_PATH / MAGICK_FILTER_MODULE_PATH / MAGICK_CONFIGURE_PATH at the bundle before it initializes Magick (set_magick_paths_win() in src/cvc/image/magick_io.cpp). This PR fixes the layout lookup that remained broken and adds a test that runs with none of those variables set.

What was actually wrong

Three suspects were open: a different CRT inside ImageMagick, the bootstrap running after genesis had cached the path, and the bootstrap never being reached. A standalone exe linked against the same deps ImageMagick (7.1.2) ruled out the first two:

• MagickCore imports GetEnvironmentVariableW and no CRT getenv, so it reads the OS environment block. _putenv_s writes that block as well as the CRT's copy. The exe saw the variables, and Magick decoded xc: and PNG after an in-process _putenv_s.
• The module path is read each time a module is opened, not cached. Setting the variables even after a failed xc: lookup fixes the next lookup.
• IsMagickCoreInstantiated() is false at main, so the bundle has no DllMain genesis that could run before libcvc.

The failures seen on 2026-10-09 came from the third suspect: Magick was reached without the bootstrap. #673 has since fixed that, and it also tries the directory of the loaded CORE_RL_MagickCore_.dll. What remained:

• The layout guess dllDir\..\..\..\..\deps\bin matches no common layout. This PR tries <ancestor>\deps\bin for the first four ancestors of cvc.dll's directory instead, which finds <root>\deps next to <root>\build-X\bin (or bin\Release). A deps prefix named in the environment (CVC_DEPS_PREFIX / LIBCVC_DEPS_PREFIX / CVCPKG_PREFIX) now comes before this guess.
• When no directory has coders, nothing is set. Before, the variables were pointed at cvc.dll's directory, which has no coders. That also hid the registry paths of an ImageMagick that is installed.
• MAGICK_CONFIGURE_PATH is set only to a share\imagemagick that holds .xml config. The lookup also covers a <prefix>\debug\bin layout (<prefix>\share\imagemagick), which CI's Debug lane uses.
• "Already set" is now checked against the OS environment block, the one MagickCore reads, instead of the CRT's copy. A user's override still wins.

New test: magick_bootstrap_test

This is a separate executable, because the bootstrap runs once per process. During static initialization, before anything can initialize Magick, it removes the three MAGICK_* variables and records whether Magick was already up. Then:

• ReadsXcWithoutMagickEnvironment (all platforms): cvc::init_imagemagick() alone makes xc: work.
• PointsMagickAtTheCoderModules (Windows): the variables it set name a directory with IM_MOD_RL_png_.dll and a config directory with .xml files.
• RoundTripsPngAndJpegWithoutMagickEnvironment (Windows): PNG and JPEG are written and read back through Magick++ directly. cvc::image reads both with stb first, so it can't prove that Magick's own decoders load.
• CvcImageRoundTripsTiffWithoutMagickEnvironment (Windows): TIFF goes through cvc::image, which has no stb path for TIFF in either direction.

CI sets the MAGICK_* variables for the whole Windows ctest step, so until now no test exercised the lookup there. This PR leaves that CI step alone.

Verification (Windows, MSVC 14.44, Release, shared, ImageMagick ON)

Build tree C:\Users\tfx\src\cvc\build-magickboot, a sibling of the deps prefix. Every run has no MAGICK_* and no CVC_DEPS_PREFIX unless the layout says so. The runs are image_test (all 28 tests), cvc_cli_test --gtest_filter=*Vol2Img*:*Img2Vol* and magick_bootstrap_test.

Layout	master (82a3901)	this PR
A: build\bin + deps\bin on PATH (normal dev run)	pass	pass
B: A with CORE_RL_*.dll copied into build\bin, so the loaded ImageMagick has no coders beside it	fails: ImageTest.ReadsCmykInputAsRgb, both CvcCli cases, all 4 new tests (NoDecodeDelegate xc:, MAGICK_CODER_MODULE_PATH=...\build-magickboot\bin)	pass
C: B + CVC_DEPS_PREFIX	pass	pass
D: A + the MAGICK_* values CI sets	pass	pass

ctest -R "MagickBootstrapTest|ImageTest|CvcCliTest.(Vol2Img|Img2Vol)", with no variables set and one process per case: 34/34 passed. Linux and macOS weren't built locally. On those platforms the new executable only runs the xc: case, which ImageTest.ReadsCmykInputAsRgb already does unguarded.