fix: prevent schedutil deadlock on Samsung Snapdragon devices

[dyokism]

Fixes #114

This PR fixes a critical bug where the schedutil CPU governor causes an infinite loop and 100% CPU usage on Samsung Snapdragon devices.

Bug
When we force the schedutil governor on modern Samsung Snapdragon devices, it creates a math problem. The generic Linux system uses PELT (smooth averages) to read CPU load, but Samsung hardware uses WALT (instant spikes). Because of this mismatch, schedutil gets confused and asks the hardware for maximum speed all the time. The hardware thermal limits (LMh) reject this request to stop overheating. However, schedutil doesn't know how to wait, so it retries the request millions of times per second. This endless loop completely freezes the Prime Core at 100% usage.

Solution
I created a global safety rule for Samsung Snapdragon devices. Now, the app and shell scripts will automatically block any requests for the schedutil governor on these specific devices. Instead, it will safely switch to the walt governor, which prevents the lockup completely.

[Rem01Gaming]

After reviewing your PR, I see that you blindly applying walt governor for all Samsung Snapdragon devices. In older devices that doesn't have walt governor, this will fail to set the correct governor.

Please note that walt governor is basically the modified version of schedutil made by Snapdragon to suits their chipset configuration, it was created because GKI doesn't allow them to directly modify schedutil governor, in old pre-gki kernels (<=4.19) they directly modify the schedutil and left the name as it is.

This make me question:

walt governor is NOT Samsung specific, are your sure the problem is Samsung Snapdragon devices specific?

Or even better question, do you understand how the "math problem" actually happens when Snapdragon device are using schedutil that your AI mentioned? Can you elaborate it?

[dyokism]

Hi! Thanks for the review.

Here is the "math problem" on modern GKI devices:

1. Standard schedutil expects PELT, but Snapdragon uses WALT.
2. When schedutil receives these bursty WALT inputs, its formula immediately requests the maximum frequency.
3. If the phone is warm, Samsung's hardware thermal limits (LMh) clamp the maximum frequency.
4. Schedutil's real-time thread (sugov) is unaware of this clamp and enters an infinite loop trying to apply the frequency, pinning the Prime Core to 100%.

To fix this, I updqted the script and daemon. They now check if walt exists in /cpufreq/scaling_available_governors before applying the bypass. If walt is missing, we leave schedutil alone.

And, on older devices, the schedutil governor was modified by Qualcomm directly to support WALT, so it is safe and does not deadlock.

LMK if you need any changes