fix(windows): report the Arc B390 as an integrated Xe3 part (#376)

## Summary

An Intel Arc B390 is an integrated Xe3 (Panther Lake) GPU. all-smi finds the device but attaches three wrong values to it: `Discrete`, `Xe-LPG (Meteor Lake)`, and a 128 MiB total memory. Each comes from a separate premise that was true when it was written and that current hardware has invalidated. All three are confirmed by reading the source, and all three are fixed here.

The memory defect lives in `windows_gpu_perf.rs`, which is new since v0.25.0 and has never shipped, so this is the difference between releasing it correct and releasing it wrong for the first time. It is also shared with `amd_windows.rs` through `augment_gpus`, so it moves every Radeon APU on Windows as well.

## The three defects

**Discrete/integrated.** The rule read "an Arc name with a model number" as "discrete card". That held until Panther Lake, the first Intel iGPU generation sold under a model number. It cannot be repaired as a pattern, because the integrated B390 and the discrete B380 differ by one digit. It is now an explicit table of the SKUs this project already claimed as discrete, plus a table of the numbered integrated parts (Lunar Lake's 140V/130V, which previously escaped the old test only by accident, and the B390). A name carrying a number that neither table knows returns **no answer at all** rather than guessing, and the DXGI memory layout fills it in instead. Owning a dedicated pool versus addressing a shared aperture is the definition of the distinction, so DXGI answers it directly rather than by inference from a marketing string.

**Architecture.** `IntelArchitecture` had no Xe3 variant, so the B390 fell through to a residual rule whose comment claimed any remaining `arc` + `graphics` name must be the Meteor Lake iGPU. Xe3 is now a variant, the residual rule is narrowed to unnumbered names only, and a numbered part the table does not recognize reports `Unknown` instead of being assigned to Meteor Lake by elimination.

**Memory.** The branch assumed integrated graphics report no dedicated pool at all, falling back to the shared aperture only when the dedicated pool was exactly zero. Modern Intel and AMD integrated parts publish a small stolen-memory carve-out through DXGI, and 128 MiB is the classic value, so the branch took the carve-out as the whole capacity. A pool below 1 GiB is now treated as a carve-out and the shared aperture is reported instead. No discrete card has ever shipped with less than that floor and the stock carve-outs are 64 to 512 MiB, so the two populations separate with room on both sides. A firmware-configured carve-out at or above the floor is still reported at face value, since that is the amount the operator set aside.

## Making the rules reachable by a test runner

Both name rules move into `intel_gpu_names`, which is pure string matching, and that module's gate gains a `test` arm. This is the substance of the fix rather than tidying.

The discrete/integrated rule lived in `intel_gpu_windows`, which is `cfg(target_os = "windows")`. No runner this project has ever compiled it, so the wrong rule was unreachable by every test job and could only be found by someone holding the hardware. `intel_gpu_sysfs`, `windows_gpu_perf` and `amd_adl` already carry the same `test` arm, and `mod.rs` states the reason next to each. This applies it to the module that just demonstrated why it matters.

## Verification, and its limits

No B390, no Windows host, and the self-hosted runners are down for maintenance. Everything claimed below was actually executed; nothing is inferred.

- **3406 tests pass**, 0 failures. 16 are new: the B390 itself, the one-digit B380/B390 collision, the deferral for unknown numbered parts, the AMD APU carve-out range (64/128/256/512 MiB), the discrete floor boundary, and regression guards pinning every SKU and architecture that was already classified correctly.
- `cargo clippy --lib --tests --all-features` produces no new warnings (the pre-existing `src/doctor/bundle.rs` one is untouched), and `cargo fmt --check` is clean.
- **The Windows-only reader was type-checked, linted, and its tests run**, using the probe technique this repository documents in `src/service_cmd/mod.rs`: a scratch worktree with a stubbed `wmi` crate and the module's gate widened, so the real `intel_gpu_windows.rs` compiles against the real `GpuInfo`, the real `windows_gpu_perf`, and the real classifier. `cargo check --target x86_64-pc-windows-msvc` still dies in `zstd-sys` for the reason #357 records, so this is the only route available. Probe reachability was proven rather than assumed: a deliberate type error injected at the changed line produced a compile error through the probe, and reverting it returned a clean check. All 22 of that module's own tests pass through it.

**What is not verified:** the B390's actual reported values. No one has run this against the device. The classification is verified against the name string the issue records, not against WMI output from the machine.

## One unrelated fix carried here

`cargo clippy -- -D warnings`, the command CI runs, fails on `main` today on a macOS host: `TempKeyScan::scanned_keys` and `total_keys` are diagnostic counters read only by tests, so they are dead behind the binary's module root exactly as `used_sorted_range` already was. It arrived with #375 and CI did not catch it, because `smc.rs` is macOS-only, the job that runs clippy runs on `ubuntu-latest`, and the one macOS job runs `cargo build --bin all-smi` alone with no clippy and no tests. That is the same blind spot #368 describes for Windows, one platform over.

It is fixed here rather than left for a separate PR because it is a one-line waiver on code this branch already had to lint past, and leaving `main` red under its own CI command is worse than the small scope bleed. Both items now carry the waiver that the neighbouring items in each file already use.

## Not addressed, deliberately

- **The missing-utilization symptom.** The issue frames it as a hypothesis needing the device and it cannot be settled from the source. `UTILIZATION_ENGINE_TYPES = ["3D", "Compute"]` in `windows_gpu_perf/ids.rs` is the candidate, and it is recorded in the follow-up rather than guessed at here.
- **Temperature.** An explicit non-goal: the part exposes no Sysman thermal sensor, so a criterion for it could never pass.
- **The two `intel_gpu_level_zero/apply.rs` sites** referenced by the archived original issue body. That analysis was lost with the draft and the module is behind `--features level_zero`, which no shipped artifact enables. The coordinates are recorded in the follow-up so they are not lost a second time.

Closes #364