test: read the PDH engine instance names on an Intel Panther Lake host

## What this issue is

A manual verification task, not an implementation task. It needs a Windows host with an Intel Panther Lake integrated GPU (Arc B370/B380/B390 or a 100-series Core Ultra part). If you have one, the whole thing is four commands and a paste; nobody without that hardware can do any of it.

Split out of #377, which mixed this with a source-reading task that needs no hardware. #377 keeps the latter.

## Why it cannot be settled from the source

`detail` reports no GPU utilization on a B390. The candidate cause is `UTILIZATION_ENGINE_TYPES` at `src/device/readers/windows_gpu_perf/ids.rs`:

```rust
pub const UTILIZATION_ENGINE_TYPES: &[&str] = &["3D", "Compute"];
```

`aggregate_engine_utilization` drops every PDH `\GPU Engine(*)` instance whose `engtype_` suffix is not in that list. If the Xe3 driver names its engines differently, every sample is filtered out and the adapter reports nothing. That is consistent with the symptom and remains a guess until somebody reads the actual instance names off the device. Guessing at it and shipping a change would be worse than leaving it open.

Note the shared surface: `amd_windows` reaches the same aggregation through `augment_gpus`, so any change to the filter moves AMD on Windows too. That is part of why this wants evidence rather than a plausible patch.

## Procedure

Build from source on the Panther Lake host. `protoc` is not needed; the TPU protos are Linux-only. Do not pass `--features level_zero`: `build.rs` emits the `all_smi_level_zero` cfg for every Windows target, so a plain build already includes the backend, and passing the flag would test a configuration that is not shipped.

```powershell
git clone https://github.com/lablup/all-smi
cd all-smi
cargo build --bin all-smi
```

### Step 1: the raw PDH instance names, which is the decisive evidence

```powershell
typeperf "\GPU Engine(*)\Utilization Percentage" -sc 1
```

Paste the full output. The part that matters is the `engtype_` suffix on each instance name. If those suffixes are `3D` and `Compute`, the hypothesis above is wrong and the cause is elsewhere, which is just as useful an answer.

### Step 2: what all-smi makes of the adapter

```powershell
.\target\debug\all-smi.exe doctor --verbose --only windows
.\target\debug\all-smi.exe doctor --only level_zero --json
```

Paste both. `windows.gpu.perf_counters` reports the adapter, its capacity and which memory pool that capacity came from, whether the PDH query opened, and how many per-process rows it saw. The `level_zero` block reports whether the loader was found, whether Sysman initialised and by which route, and how many devices it enumerated. Those four Level Zero checks have never run against an Intel GPU.

### Step 3: what the TUI shows

```powershell
.\target\debug\all-smi.exe local
```

Report the GPU row: utilization, memory used and total, temperature, power, clock. Say which of them are blank. Temperature being absent is expected and is not a defect: this part exposes no Sysman thermal sensor, which #364 recorded explicitly.

### Step 4: the WMI baseline, for comparison

```powershell
Get-CimInstance Win32_VideoController | Select-Object Name, AdapterCompatibility, AdapterRAM, PNPDeviceID
```

`AdapterRAM` is a `uint32` and saturates at `0xFFF00000` (4293918720) for anything larger, so comparing it against what `doctor` reports shows whether the DXGI path is doing its job on this part.

## What a complete report looks like

Everything above pasted as text, plus the machine: exact CPU or GPU model, Windows build (`winver`), and driver version from step 4. A report with step 1 alone is already enough to settle the main question.

## Acceptance criteria

- [ ] The raw PDH `\GPU Engine(*)` instance names from a Panther Lake host are recorded in this issue
- [ ] The engine-type hypothesis is either confirmed, with a fix and tests that run on the available runners, or refuted in writing
- [ ] If a fix changes the engine-type filter, its effect on AMD Windows adapters is stated, because they share the aggregation
- [ ] The `level_zero.*` doctor checks are recorded from a host that actually has an Intel GPU, which has never happened

## Why the CI runner cannot do this

`windows-on-macmini02-x64` is a VMware virtual machine whose only display adapter is a `VMware SVGA 3D`. Measured in run 32705270378. It has no Intel GPU, so `level_zero.loader` correctly skips with "no Level Zero loader found and no Intel GPU present" and none of the paths above are reachable there.

## Related

- #377: the source-reading half that was split out of, which needs no hardware
- #364: the three root causes that were fixed, and the archived note these came from
- #376: the classification and capacity fixes, which shipped in v0.26.0

On a Windows host with an Intel Panther Lake GPU, build the plain binary with `cargo build --bin all-smi` and read `src/device/readers/windows_gpu_perf/ids.rs` before running the documented `typeperf` command. Paste the PDH names, both `doctor` outputs, the `local` GPU row, and the WMI baseline; done means confirming or refuting the engine-type hypothesis and documenting any AMD impact if a filter change is needed.

Written by the indexing model from the issue text.