fix: transient WMI fault no longer poisons the static-hardware cache for the session

[laurentiu021]

Summary

Fixes ultra-audit finding P2 #40.

SystemInfoService caches static hardware info with ??=, but every Query* helper returned a non-null fallback on a WMI fault (CpuInfo("Unknown", …), OsInfo("Windows", …), an empty disk/module list). Because the fallback was non-null, ??= stored it and never re-queried. So if the first CaptureAsync raced a transient WMI fault — plausible under the app's documented ~36-service startup thundering herd → RPC server too busy (0x800706BB) — the fallback defaults were cached process-wide (the service is a singleton) even after WMI recovered milliseconds later. The Dashboard, System Info tab, System Report and tray tooltip then permanently showed "Unknown CPU" / "Windows" / no disks / no RAM modules until the app was restarted.

Fix

Cache only a successful query:

• QueryOsStatic / QueryCpuStatic return null on a WMI fault (a successful no-rows result still returns the "unknown" answer and is cached).
• QueryDisks / QueryMemoryModules return null only when a fault yielded nothing; a genuinely empty-but-successful enumeration (or a partial list gathered before a fault) is a usable answer and is cached.
• Capture uses a transient, non-cached default for the current snapshot when the cache is still null, so ??= retries on the next poll.

Regression test (integration)

CaptureAsync_ReQueriesStaticInfo_AfterCacheCleared: after a successful capture populates the cache, nulling _cachedCpuStatic (the post-fault state the fix now produces) and re-capturing must repopulate a real CPU — proving a cleared/null cache is retried, not left permanently degraded. Red before the fix (the fault path cached a non-null fallback, so the cache was never null to retry).

Checks

• All 3 projects build 0 warnings / 0 errors
• Leak scan on diff: clean
• Behavior unchanged on the happy path (WMI healthy): static info still queried once and cached