Windows AMD discovery on unified-memory hosts: identity-only first?

[Kenneth-Javier]

Hi @JustVugg — after #788 shipped in v1.5.0, I audited the current Windows AMD
resource-planning path before starting the next Windows HIP contribution.

The deeper HIP execution ABI is already available through the Windows loader,
but resource_plan.py currently cannot discover an AMD device on Windows
because _discover_amd_gpus() relies on rocm-smi, which the Windows HIP SDK
does not ship.

The Windows SDK does provide hipInfo.exe, and it can report:

• device identity and name
• totalGlobalMem
• isIntegrated

It does not report free memory.

There is an important state-model issue: simply returning an AMD GPU with
free_bytes = 0 would not be a safe identity-only implementation.

_auto_tune() currently uses bool(gpus) before the VRAM-budget gate, so a
discovered but unqualified device could still:

• emit COLI_CUDA_PIPE=1
• change bottleneck_class to mixed
• change the resulting DRAFT recommendation

I also found that the Windows doctor linkage check currently looks only for
coli_cuda.dll. Once an AMD device becomes visible, a valid HIP installation
with coli_hip.dll could therefore be reported as:

NVIDIA GPU detected but the engine is CPU-only

My proposed first slice is deliberately conservative:

1. Discover the Windows AMD device through hipInfo.exe.
2. Represent it as detected but not yet qualified for memory planning.
3. Use an explicit state such as:
   • free_bytes = None
   • planning_eligible = false
4. Show the device and HIP backend truthfully in coli doctor.
5. Exclude identity-only devices from:
   • auto-tuning
   • VRAM budgeting
   • expert-tier environment overrides
   • bottleneck classification
6. Make the Windows linkage check recognise both coli_hip.dll and
   coli_cuda.dll.

A later, separately validated slice would define the shared-memory budget
contract and could use the HIP runtime's real free-memory query before enabling
automatic placement on integrated AMD devices.

Would you prefer this identity-only first step, or would you rather have
Windows AMD discovery go directly through a new runtime-backed query that can
return real free bytes?

I have not created a branch or implemented anything yet because this choice
changes the appropriate scope and ownership of the first patch.