Start keymon on TrimUI A133P so Fn key mappings work

[Felixmil]

On the TrimUI Brick, the "Fn Key and Switch Settings" app lets you map actions to the left/right Fn keys, but pressing them did nothing. This restores Fn key support by starting the stock keymon daemon, which is the component that reads the editor's mappings and runs the chosen action on a key press.

Root cause

The Fn keys are dispatched by the stock keymon daemon (/usr/trimui/bin/keymon), which loads /usr/trimui/fnkeys/f1key.json and f2key.json and runs the mapped action script on key press. On stock firmware keymon is launched by runtrimui-original.sh. spruce replaces that boot path and starts the other TrimUI blobs in device_init_a133p (trimui_inputd, trimui_scened, trimui_btmanager, hardwareservice, musicserver) plus trimui_osdd, but it never started keymon. As a result the editor saved mappings that nothing was running to act on.

The physical switch was unaffected: it is handled by the separate trimui_scened daemon (already running) via scene.sh, so it kept working.

Change

keymon is added to the blob list started in device_init_a133p (spruce/scripts/platform/device_functions/trimui_a133p.sh). run_trimui_blobs already changes into /usr/trimui/bin, skips a blob that is absent or already running, and launches it with the correct LD_LIBRARY_PATH, which is exactly how keymon needs to run, so no other plumbing is required. keymon is also a known part of spruce input handling on other devices (the A30 path documents "ensuring keymon is running", and MiyooMini starts it), so this brings the A133P devices in line. Because run_trimui_blobs is a no-op when the binary is absent, the addition is safe for the other devices that share device_init_a133p.

Validation

Tested on a physical Brick (FW 1.1.1) over SSH, from a clean reboot. keymon autostarts from the patched script (confirmed in the process list after boot), and volume keys, the power button, and the other daemons continue to behave normally with it running (no double-handling or crash observed).

Every action the editor offers was exercised on hardware. All work except the CPU clock switcher:

Action	Mapped to	Result
LED ON/OFF toggle	Fn key	works (LEDs go off and back on)
LCD brightness switcher	Fn key	works (see related backlight PR for slider sync)
CPU clock switcher	Fn key	does not work, see note below
LED off	switch	works (LEDs restore on flip up)
Quiet Mode	switch	works
Silent Mode	switch	works
Joystick Toggle	switch	works

The CPU clock switcher cannot work under spruce by design. Its script (com.trimui.switch.cpufreq.sh) writes directly to /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq and scaling_max_freq, but spruce manages CPU scaling through its own performance profiles and those nodes are not writable here, so the writes fail with "Permission denied" and the clock does not change. This is not a regression from this PR (the action was already non-functional); it is left in place and can be removed from the menu in a follow-up.

Related issues

Fixes #1440

Fixes #1319 (Brick LED switch not restoring lights). Confirmed on hardware: with keymon running, both the Fn key LED toggle and the switch LED off action turn the LEDs off and back on (/sys/class/led_anim/enable tracks the switch state).