feat(plan): discover Windows AMD GPUs without planning against them

[Kenneth-Javier]

Summary

Device discovery does not imply planning eligibility.

• Windows AMD discovery currently depends on rocm-smi, which is not available through the Windows HIP environment used by this path. Windows AMD hosts were therefore planned as if no GPU had been discovered: nothing in coli plan, "no supported GPU detected", and --gpu N failing on working hardware.
• This change uses hipInfo.exe for Windows AMD identity reporting: device name, architecture, integrated flag and reported total memory.
• Integrated Windows AMD devices are reported with free_bytes=None. They remain visible to reporting while being excluded from automatic placement until a qualified free-memory budget exists.
• The Windows launcher uses the same placement-eligibility predicate, and doctor checks the backend artifact the host was built to load.

Design background: Discussion #857. This PR does not close it.

Why

Discovery is a fact; a placement budget is a policy decision, and the planner had no way to separate them: free_bytes was mandatory and numeric, and every consumer read "a GPU is present" as "a GPU may be planned against". That reading stops holding when the GPU and the host draw on one physical pool.

free_bytes may now be None, meaning "not qualified as a budget on this platform". It is deliberately distinct from 0, which is a measurement ("the card is full"); plans_placement() tests is not None rather than truthiness so the two cannot collapse. Existing devices with numeric free_bytes retain their current planning semantics.

Implementation

1. Discovery — _discover_amd_gpus() gains a Windows branch. hipInfo.exe is located from COLI_HIP_RUNTIME_DIR, then %HIP_PATH%\bin, then PATH, stopping at the first hit; the Colibri-specific runtime directory leads because it names the runtime the loader will bind, and a host may carry more than one HIP install. No install location is hardcoded, and no new dependency is introduced — hipInfo comes from the HIP environment already required to build the backend. A block missing a name or a memory total yields no device rather than one completed with zeros, and missing, failing or unparsable hipInfo yields no device at all. The Linux rocm-smi path is untouched.

2. Planning boundary — only devices whose free memory is qualified reach the VRAM budget, the shared-pool unified flag, _auto_tune, the bottleneck classification, the "VRAM already in use" warning, and the COLI_GPU/COLI_GPUS device list. Everything discovered still reaches reporting, marked (identity only) with a warning naming it. The launcher has a separate auto-enable path that writes COLI_CUDA/COLI_GPUS before environment_for_plan() is consulted, so it filters through the same predicate rather than a second local rule.

3. Doctor — the Windows probe required coli_cuda.dll regardless of what the host was built to load, so a working HIP install reported "GPU runtime library is missing", which is a fail and makes the whole report error. backend_loader.c compiles exactly one basename into the host (COLI_BACKEND_DLL), so the binary states which artifact it will load and doctor now checks for that one. A CUDA host still requires coli_cuda.dll; a HIP host requires coli_hip.dll; neither is satisfied by the other.

Validation

• make -C c check — 508 tests, OK, 52 skipped, exit code 0
• CUDA changes were tested with make -C c cuda-test (if applicable) — N/A, no CUDA or C code is changed
• Performance claims include hardware, commands, and repeatable measurements — N/A, no performance claim is made

On the local MSYS2 GCC 16.1 toolchain the check also emits existing compiler warnings from unchanged C test translation units; this PR changes no C or header files.

Targeted owner run:

python -m unittest tests.test_env_defaults tests.test_resource_plan tests.test_doctor
  -> 98 tests, OK

Twenty-three tests were added to three existing owners; no new test file. The contract is reviewable without AMD hardware:

• CPU-only and no-GPU behaviour unchanged
• numeric-free_bytes devices retain existing planning behaviour, including free_bytes=0
• an identity-only device produces an environment byte-identical to the CPU-only host's
• Windows hipInfo parsing: integrated, discrete, multi-device, absent, non-zero exit, incomplete block, lookup precedence
• Linux rocm-smi discovery preserved
• doctor accepts each host's own backend and rejects the other's
• launcher auto-enable regression, both directions

Physical validation on AMD Radeon 8060S / gfx1151, Windows. Four controlled observations, each in its own rebooted session, varying the firmware shared-memory setting:

shared-memory setting	HIP total	Windows visible
~6 GB	76.79 GiB	127.15 GiB
~32 GB	76.79 GiB	127.15 GiB
~64 GB	76.79 GiB	127.15 GiB
~123 GB	93.00 GiB	127.15 GiB

The static HIP values are not a qualified direct budget for the tested shared-memory setting.

Compatibility

• The default CPU build remains dependency-free
• No model files, generated binaries, or benchmark artifacts are included
• Linux AMD, Windows NVIDIA and CPU-only behavior is covered by regression tests; no macOS-specific path is changed

Not in this PR

Automatic Windows AMD shared-memory budgeting; dynamic allocation qualification; performance tuning; zero-copy claims; routed-expert placement; KV work; the Windows memory_available() fix; HIP-aware cuda_binary().

No performance improvement or automatic Windows AMD placement is claimed. The change enables truthful discovery while deliberately withholding automatic placement until a qualified free-memory budget exists.