Treat thermal zones with never-changing readings as unavailable

[HPoyisis]

Context of Contribution

• Bug Fix
• Refactoring
• New Feature
• Others

Summary of the Proposal

On some machines the ACPI thermal zone exposed through the "Thermal Zone Information" performance counter is not wired to a real sensor and always reports a fixed placeholder value. On a GIGABYTE AERO 15 KC (Windows 11), the only zone \_TZ.TZ00 constantly reports 301 K (27.85 °C) even under sustained full CPU load — while the real CPU package temperature at the same moment was 88 °C (verified with LibreHardwareMonitor). RunCat 365 therefore permanently shows a misleading ~28 °C in the notify icon tooltip and the system info menu.

This PR tracks whether the thermal zone readings have ever changed since startup. After 24 identical consecutive reads (about 2 minutes at the current fetch cadence of one temperature update per 5 seconds), the zone is treated as a placeholder and the temperature entry is hidden — the same behavior as on machines that expose no thermal zone at all. Detection is self-correcting: readings are still taken on every update, and if any value ever changes, the temperature is shown again permanently.

To keep false positives out, variation is tracked on the "High Precision Temperature" counter of the same category (0.1 K granularity) when it is available: a live sensor jitters at that resolution even when the whole-Kelvin "Temperature" counter legitimately stays flat on an idle machine. When the high-precision counter is unavailable the tracking falls back to the Temperature counter values; the tracking source is fixed at construction so readings are never compared across the two counters' different scales. (On the affected machine the placeholder zone reports both counters bit-identical forever: Temperature = 301, High Precision = 3010.)

Residual trade-off: on firmware whose high-precision counter is just a ×10 copy of the whole-Kelvin value, a genuinely constant sensor could still be hidden after the 2-minute window until its reading first drifts. The failure mode is temporary hiding of a stale-looking value rather than showing wrong data, and it heals permanently on the first observed change.

Verified on the affected machine: with this change the placeholder zone is hidden after 2 minutes; the change builds with 0 errors and no new warnings, adds no dependencies, and does not alter behavior on machines whose thermal zones report real (varying) values.

Reason for the new feature

N/A (bug fix).

Checklist

• I have read the CONTRIBUTING.md and agree to follow it.
• This PR does not contain commits of multiple contexts.
• Code follows proper indentation and naming conventions.
• Implemented using only APIs that can be submitted to the Microsoft Store. (Uses the already-referenced performance counter API only; no new dependencies.)
• Works correctly in both dark theme and light theme. (No UI change.)
• Works correctly on any device. (Pure logic change on the existing counter path; machines with varying thermal zone readings are unaffected.)