Optional fan sync to hottest sensor for shared heatsinks

[Lafnaps]

Hi, this adds an opt-in workaround for something that's been bugging me on my M16 (GU604VY) and was asked before in #4411.

With a custom fan curve applied, EC ties each fan strictly to its own sensor. On a shared heatsink this gives two effects:

• GPU fan stays at ~2000 rpm while the CPU sits at 95C, even though both fans cool the same heatpipes
• when the dGPU keeps dozing off and waking up, its fan starts and stops every couple of minutes (EC seems to jump between the GPU sensor and the CPU fallback), which is quite audible in a quiet room

Stock profiles don't do this, fans there follow the hottest component more or less.

What the patch does: a new "Sync Fans to Hottest Sensor" checkbox in Fans + Power. While it's enabled (and only while custom curves are actually applied), a 3s timer takes max(cpu, gpu) temp and re-applies each fan's own curve with the speed points raised to at least what that curve prescribes at that temp. So it's still the usual fan curve endpoint and EC still does all realtime control - fans just can't drop below the "hottest sensor" floor. Curves are only rewritten when the floor actually changes (2C step), so at steady temps there is no extra ACPI traffic at all.

Sync is stopped around calibration, factory reset and sleep/shutdown resets so it never fights them, and it stays inactive when curves are off or were rejected by firmware.

Tested on GU604VY (3 fans incl. mid): CPU load at 95C takes the GPU fan from ~2100 to ~3900 rpm; calibration, mode switching and plug/unplug behave as before with the option off. I understand fan logic is a sensitive area - the feature is fully opt-in and defaults to off.

[seerge]

@Lafnaps hello, it's already possible with https://github.com/seerge/g-helper-experimental-release that has a proper manual fan control

Adjusting fan curve won't achieve this anyway, as it's still up to a free firmware interpretation :)

[Lafnaps]

Thanks for the reply! I did check out the experimental build before going this route. My main concern with proper manual control is the failure mode: the app is now the thing driving the fans, so if it crashes or gets killed, the fan is left stuck at whatever was last set, with nothing watching the temps anymore.

That's exactly what this PR avoids - the firmware stays in charge the whole time. All it does is raise the floor of the curve that gets written to the EC, so the worst case (app dies) is just a valid curve that the EC keeps executing on its own. Fail-safe by design.

On the "free firmware interpretation" point - fair, but I did verify it on real hardware (GU604V): with a hot CPU and an idle dGPU, writing the synced curve took the GPU fan from ~2100 to ~3900 rpm, so both fans end up spinning at the speed the hottest sensor calls for. Which is exactly what #4411 was about.