obs-gpu-status: Keep one PDH query open between label ticks

[vpacher]

Refs #1022

What and why

The follow-up from the review of #1264: gpu_engine_samples() opened a PDH query, added the counter, collected twice 100 ms apart and closed the query, on every label tick. On an RTX 3060 that cost about 230 ms per tick (900 ms for the first), and the value covered only 100 ms of the second.

This PR keeps one query open:

1. pdh::PdhTicker (Tier 1, platform-neutral) keeps one EngineCounters query and returns the utilization since the previous call. The first call after the query opens only primes it (Unavailable). A failed query, or a failed open, is retried on the next call.
2. platform/windows.rs: EngineQuery opens \GPU Engine(*)\Utilization Percentage and adds the counter once; each tick is one PdhCollectQueryData and the read of the array (the read code is unchanged, now read_counter()). No 100 ms sleep: the previous tick is the baseline, so the value is the average over the second since then.
3. PdhSource keeps one ticker. gpu_engine_samples() stays as a one-shot read (open, prime, 100 ms, read) for the probe.
4. The probe takes three label samples one second apart, as the frontend's sampler thread does.

RED → GREEN

• Rebased onto master after obs-gpu-status: Windows GPU: x% from PDH GPU Engine counters #1264 merged (by zackees; the patch is unchanged).

• RED af4f8f3: four Tier 1 tests drive PdhTicker with fake queries. With a stub that never opens a query, 3 fail: the first-tick baseline (left: Unavailable, right: Percent(37)), the reopen of a failed query (Percent(25)) and the retry of a failed open (Percent(9)). The render-adapter filter passes with the stub.

• GREEN f9f801b: 133/133 crate tests pass on macOS. 8b15895 names the fake query results in the tests (clippy type_complexity, which Fast Gate caught: my local clippy output went through a filter that missed soldr's timestamp prefix). Now clippy -D warnings finishes clean for aarch64-apple-darwin and x86_64-pc-windows-msvc, checked on the Finished line. fmt is clean.

• Real hardware: the same Windows 11 VM with the RTX 3060 (driver 617.42) as obs-gpu-status: Windows GPU: x% from PDH GPU Engine counters #1264, the old probe (a new query per sample) and the new one (three ticks per run), idle and under a GPU-bound WebGL load:

  	Old: new query per sample	New: query stays open
  First sample	906 ms, 925 ms	123 ms, 124 ms, 147 ms (open and prime, once)
  Each later tick	228 to 234 ms	0.36 to 0.55 ms
  Under load (nvidia-smi 30 %, then 39 %)	0 %, 30 %, 59 %	30 %, 33 %, then 32 %, 38 %

  A tick is about 500 times cheaper, and the one-second average follows nvidia-smi more closely than the 100 ms window did.

• Real app: not applicable (no change in what the label shows, only how often the source costs time). The Windows app check for frontend: GPU: x% readout replaces the GPU status light #1025 waits for a beta that has obs-gpu-status: Windows GPU: x% from PDH GPU Engine counters #1264.

Checklist

• Base is master (or the description starts with a Stacked: note)
• I claimed the issue, or no one else has an open PR for it (obs-gpu-status: Windows GPU utilization through PDH GPU Engine counters #1022 is zackees'; he handed this part over in obs-gpu-status: Windows GPU: x% from PDH GPU Engine counters #1264)
• Characterization test (if the unit had none), then RED, then GREEN commits
• User-visible change: its line in docs/features.md is added or updated (not applicable: no user-visible change)
• (Optional) Local gate passed and the pushed head is stamped; otherwise PR CI runs the full suite
• Warning or flag changes (-W..., ratchets): built with scripting ON (a flag change under cmake/ or build-aux/ runs the full builds) and cross-checked with clang and MSVC (not applicable: no flag changes)
• Intentional differences from C listed in the parity test header and rust/README.md (ports) (not applicable: new code, no C original)

🤖 Generated with Claude Code

[zackees]

@vpacher Fast Gate fails on clippy type_complexity at rust/obs-gpu-status/tests/gpu_status/pdh.rs:184 ("very complex type used. Consider factoring parts into type definitions"); a type alias fixes it, and ./lint catches it locally. Also, this carries #1264's three commits, so it's stacked: I'll queue #1264 first, then this once it's rebased onto master and green.

[vpacher]

@zackees Fixed in 21a73be: a Collections type alias for the fake query results. Thanks for the catch. My local clippy output went through a filter that missed soldr's timestamp prefix, so it hid the error; now checked on the Finished line for macOS and x86_64-pc-windows-msvc. Understood on the order: I'll rebase this onto master once #1264 merges and drop the stacked note.

[zackees]

#1264 merged, so I rebased this onto master and dropped its three commits; your three remain (8b15895). Clean rebase, ./lint passes. Will queue once CI is green.