## Resume from sleep leaves panel dark on Lenovo LOQ 15ARP9 (NVIDIA dGPU-only, s2idle)

**Hardware:** Lenovo LOQ 15ARP9 (83JC), RTX 4050 Max-Q Mobile, no iGPU (dGPU-only), BIOS PQCN31WW, `mem_sleep: [s2idle]` only
**Software:** Omarchy 4.0.4-1, `linux-omarchy 7.2.5-3`, `nvidia-open-dkms 610.57.04`, Hyprland (Quickshell)

### Symptom
Clicking Sleep (or `systemctl suspend`) suspends fine (`PM: suspend entry (s2idle)`), but on wake the internal panel stays black. Fans/keyboard come on, system is alive (SSH works), only the display never re-lights. Hard reboot required. Same class of failure as #4200 / #2635, and the same hardware as CachyOS/linux-cachyos#493 and NVIDIA/open-gpu-kernel-modules#1136.

### Root cause
`omarchy-system-wake` relies on `omarchy-brightness-display on` to re-enable the panel, but that command **skips** the DPMS enable dispatch when Hyprland already reports `dpmsStatus=true`:

```bash
# bin/omarchy-brightness-display
hyprctl monitors -j | jq -e '[.[] | select(.disabled == false)] | length > 0 and all(.dpmsStatus)' && exit 0
hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })'
```

After s2idle resume on this NVIDIA setup the reported `dpmsStatus` is stale (`true` while the panel is physically dark), so the enable is skipped and nothing ever re-lights the eDP panel. NVIDIA driver state is otherwise healthy (`PreserveVideoMemoryAllocations=1`, `EnableS0ixPowerManagement=1`, S0ix Status: Enabled, `nvidia-resume.service` finishes OK).

### Local workaround (verified)
Force the DPMS enable in the resume path instead of trusting the guard — patched `~/.local/bin/omarchy-resume-wake-listener` so on `PrepareForSleep(false)` it runs:

```bash
sleep 1
for _ in 1 2 3; do
  hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })' >/dev/null 2>&1 || true
  sleep 1
done
omarchy-system-wake >/dev/null 2>&1 || true
```

### Suggested upstream fix
Give the resume path a way to bypass the already-lit guard, e.g.:

- add a `--force` flag to `omarchy-brightness-display on` that skips the `jq … all(.dpmsStatus)` early-exit, and
- call it (or the raw `hl.dsp.dpms enable` dispatch with a short retry) from `omarchy-system-wake` / the resume listener.

The guard itself is still valuable for the keystroke path (avoids the unlock-screen flash noted in omarchy-mac@54d79d9) — it just must not gate the actual resume path on s2idle+NVIDIA hardware where the status is stale.

Happy to turn this into a PR against `quattro` if maintainers agree with the `--force` approach.