### System details

- Omarchy 4.0.2-1
- ASUS keyboard LED device: `asus::kbd_backlight`, maximum brightness 3
- Intel Core Ultra 7 258V; Intel Arc 130V/140V integrated graphics
- Kernel 7.1.9-arch1-2

### What's wrong?

Keyboard brightness selected with Fn+F7 does not reliably survive idle/screensaver dismissal. It is fine for the keyboard to go dark while idle or asleep, but activity should preserve/restore the last manually selected level, including an intentional off setting.

There appears to be a stale-state case separate from the repeated `off` calls reported in #7650 and #10105: `omarchy-brightness-keyboard up/down/cycle` changes the hardware level without updating brightnessctl's saved state. `omarchy-system-wake` unconditionally restores that saved state. The idle service calls system-wake when cancelling a screensaver cycle, even if the keyboard was not blanked in between.

Thus dismissing the screensaver can undo a manual brightness change by restoring an older saved level.

### Deterministic reproduction

On this device (levels 0–3), using the stock commands directly:

```bash
dev=asus::kbd_backlight
brightnessctl -d "$dev" set 2
brightnessctl -d "$dev" --save get
omarchy-brightness-keyboard --no-osd down
brightnessctl -d "$dev" get                  # 1
omarchy-brightness-keyboard restore
brightnessctl -d "$dev" get                  # 2: manual change undone
```

This was tested on the machine. There is **no intervening `off` call**, unlike the repeated-blanking reports. The original brightness was restored after the test.

Desktop reproduction to try: establish a saved level, change brightness using the keyboard shortcut, allow the screensaver to start, then dismiss it before the lock deadline. Expected: the newly selected brightness remains. Actual symptom on this machine: the keyboard setting does not stick and must be adjusted again.

### Local workaround / possible fix

The local keybindings now run this after the stock `up`, `down`, or `cycle` command:

```bash
brightnessctl --device='*kbd_backlight*' --save get >/dev/null
```

We also seeded the saved state with the current selected brightness. A direct off → restore → restore test then produced 0 → 2 → 2 as expected. Full suspend/hibernate and an end-to-end idle cycle after applying the workaround have not yet been verified; this report specifically confirms the stale-state command sequence above.

Could explicit brightness changes update the saved preference, or could restoration be conditional on an actual blanking cycle? Any fix should preserve intentional zero brightness and also account for the repeated-off problem in #7650.

Related: #7650, #10105; #7562 added the restore-on-wake behavior.

Diagnostics note: `omarchy debug --no-sudo --print` returned `Unknown Omarchy command` on this installation, so system details were gathered separately.