Persist four-zone keyboard lighting state when settings change

[RezaT4795]

Summary

This PR fixes four-zone keyboard lighting persistence for supported Acer laptops.

Previously, custom keyboard lighting could be applied successfully while the system was running, but after a reboot the keyboard would fall back to the firmware/default lighting mode, such as Neon mode.

The root cause was that the driver only saved the four-zone keyboard state when the linuwu_sense kernel module was removed. On systems where the module is not explicitly unloaded during shutdown, the latest keyboard lighting state is never written to disk.

This PR saves the keyboard lighting state immediately after a successful lighting change, making the behavior independent of shutdown/module-unload handling.

Problem

The driver already had support for saving and loading keyboard state through:

/etc/four_zone_kb_state

The saved state was loaded during module initialization, but it was only written during module removal.

That means the persistence flow depended on this happening cleanly:

user changes keyboard lighting
system shuts down
kernel module is removed cleanly
driver saves /etc/four_zone_kb_state
next boot loads saved state

On systems where the module is not explicitly unloaded at shutdown, this flow breaks:

user changes keyboard lighting
system shuts down/reboots
module is not cleanly removed through the driver's remove path
state file is not updated
next boot restores an old state or falls back to default lighting

As a result, custom four-zone keyboard lighting only lasted until reboot.

Changes

• Save four-zone keyboard state immediately after successfully applying normal four-zone RGB settings.
• Save four-zone keyboard state immediately after successfully applying per-zone RGB settings.
• Add a forward declaration for the keyboard state save helper where needed.
• Keep the existing module-remove save behavior as a fallback.
• Make the remove-path keyboard-state save condition consistent with the sysfs creation condition.

Why this fix

Saving state only during module removal is fragile because persistence should happen when the state actually changes, not later during shutdown.

The new behavior is safer:

user changes keyboard lighting
driver applies new lighting successfully
driver immediately writes the new state to /etc/four_zone_kb_state
next boot restores the latest applied state

This avoids relying on systemd service behavior, shutdown ordering, or explicit rmmod execution.

Scope

This PR only changes kernel module keyboard lighting persistence behavior.

It does not change:

• the userspace GUI protocol
• the daemon protocol
• keyboard lighting sysfs file names
• supported laptop detection
• the format of /etc/four_zone_kb_state
• the existing load-on-module-init behavior

Testing

Tested manually on Slackware with linuwu_sense installed and loaded.

Verified:

• Custom four-zone keyboard colors can be applied successfully.
• Per-zone keyboard colors can be applied successfully.
• /etc/four_zone_kb_state is updated after applying keyboard lighting changes.
• Rebooting the system restores the last applied keyboard lighting state.
• Keyboard lighting no longer falls back to the default Neon mode after reboot.
• Existing module unload behavior still saves the keyboard state as a fallback.

Notes

A separate GUI PR handles DAMX-GUI issues around Keyboard Lighting UI state, Static Mode behavior, fan mode restoration, daemon command serialization, and the Avalonia 12 upgrade.