feat(monitor): query all NPU/GPU engines and take max utilization

[xieofxie]

Summary

• PdhPoller previously locked onto a single engine per adapter (first alphabetical Compute* for NPU, 3D for GPU). On NPUs with multiple Compute_* engines, work scheduled to a non-monitored engine read as 0% utilization; on GPUs where DML lands on a Compute engine, the 3D-only query missed the activity entirely.
• build_adapter_query now takes engine_types: tuple[str, ...] and registers one util_<engtype> + running_time_<engtype> counter per matching engine. build_npu_query covers all Compute_*; build_gpu_query covers both 3D and Compute_*.
• PdhPoller._poll_loop aggregates samples with max() across util_* keys — each counter is a per-engine ratio over the same sample window, so max reports the most-loaded engine. Summing percentages would exceed 100% on multi-engine adapters and duplicate the signal that running-time already provides.
• running_time_delta_ns sums per-engine deltas — Running Time is wall-clock ns per engine, and engines are independent HW that can run in parallel, so total adapter compute time is additive.
• Adapter resolution (resolve_adapter_luid) is untouched; this only changes how counters are registered and aggregated for the resolved adapter.

🤖 Generated with Claude Code

[xieofxie]

Also tested vitisa, migraphx

[timenick]

Two findings on the multi-engine PDH aggregation: the PR is about aggregation correctness, so I want it pinned by tests and documented for future readers.