fix(doctor): act on what real Windows hardware showed (#393)

Four corrections, all of them written because a real Windows machine printed something that did not match what the code claimed. Three are the same defect in different places: a check held the value that answered the question and did not print it.

The host: Ryzen AI MAX+ 395 with a Radeon 8060S, Windows 11 Pro 26200, 128 GB physical with 96 GB allocated to the GPU in firmware, and an NVIDIA eGPU that was detached during the run.

The elevation guard told the reader to reconfigure the CI runner as an administrator. That runner reports `elevated: False` and stays that way by decision, because an elevated persistent runner executes whatever lands on main with Administrator rights and a one-off check on a dedicated machine is the cheaper risk. Issue #357 carries the decision; the workflow now agrees with it. Two references to ENABLE_WINDOWS_SERVICE_SMOKE, gone since #392, are dropped with it.

`windows.gpu.perf_counters` printed an adapter's capacity without saying whether it came from the dedicated pool or the shared aperture, and `resolve_adapter_memory` returns one or the other depending on a 1 GiB floor. I misread the CI VM's output because of that. The AMD host settles the underlying question with no ambiguity left: WMI reports `AdapterRAM` of 4293918720 for the same adapter that DXGI reports at 95.8 GiB, against a real 96 GB carve-out. 4293918720 is 0xFFF00000, the largest MiB-aligned value below 2^32, and the identical number appeared on the VM's 8 GiB adapter, which is what shows it to be a saturation artifact rather than a configured size.

`describe_readout` printed edge, hotspot and mem temperatures and omitted gfx, which is the second link in `primary_temperature_c`'s chain. A Strix Halo APU reports none of edge, mem or hotspot and does report gfx, so the dump said every temperature was absent while the TUI correctly showed 41 C from raw index 28. A field-verification dump should not need the source read to reconcile it with the product. The clock keeps its value under `gfxclk` so the two `gfx` quantities stay apart.

`check_nvml_loadable` turned every `Nvml::init()` error into a failure with no branch for the commonest cause, and `check_smi` had the same shape once the binary was found. A driver survives its hardware being unplugged, so finding nvidia-smi says nothing about a device being present. The reporting host exited 2 with two failures while entirely healthy, and unelevated it printed NVML_ERROR_NO_PERMISSION, sending the operator after an elevation problem that does not exist. Run elevated, the same host reports the real condition: it cannot reach the driver. Both checks now stand down when `has_nvidia()` is false, which is the position `level_zero.init` and `level_zero.devices` already take for Intel. The skip message does not assert "no GPU", because `has_nvidia()` asks `nvidia-smi -L` and a false answer covers no hardware, an unreachable driver, and an unelevated Windows shell; it names all three.

Validated with `cargo fmt --check`, `cargo clippy --lib -- -D warnings`, `cargo check --lib`, and `cargo test --lib doctor` at 47 passed. The NVIDIA gate does not suppress the positive path: on a Linux host that does have an NVIDIA GPU all five nvidia checks still pass and `doctor --only nvidia` exits 0.

Not compiled for their target here: the two Windows-gated changes sit behind `cfg(target_os = "windows")` with no `test` arm, and this host has no x86_64-pc-windows-msvc toolchain. Field accesses were verified against the struct definitions. The windows-checks job added in #392 compiles them on merge.