fix(stasis): give the desktop plan its own dpms and lock steps

A machine without a battery never blanked and never locked. stasis builds
the desktop plan from the blocks directly under `default:` and excludes
the ac:/battery: containers (src/config/mod.rs:180-183, :230-233), so a
config that keeps every step inside those containers leaves the desktop
plan empty. select_plan_source only falls back onto the desktop plan,
never from it onto ac: (src/core/config.rs:288-306), and the last-resort
rebuild_plan_default_order() builds from blocks the parser has already
disabled — a plan of disabled steps.

dpms (120s) and lock_screen (180s) now sit directly under `default:`,
timeouts matching the ac: plan. Deliberately only those two: brightnessctl
cannot drive external monitors, and suspending a desktop is a separate
decision from idle screen handling.

DECISIONS.md

@@ -7,6 +7,13 @@
 - **Tradeoffs**: ppd writes exactly those knobs — `ppd-driver-amd-pstate.c` / `ppd-driver-intel-pstate.c` set EPP, `ppd-driver-platform-profile.c` the ACPI `platform_profile` that auto-cpufreq never touched — and its polkit policy allows `switch-profile` for the active session, so the popout no longer loses its focus to a pkexec prompt. What is given up is auto-cpufreq's load-dependent automatic: ppd offers three fixed profiles and leaves the reacting to the firmware. It also has no `watch` subcommand, so the widget keeps its 60s fallback poll instead of becoming event-driven. moonix switched with it (its `services.power-profiles-daemon` module asserts against auto-cpufreq, so the choice is one or the other) — and since moonix deploys this repo's quickshell config, the widget could not stay on the old backend either.
 - **How**: `CpuGovService.qml` calls `powerprofilesctl get` / `set` (no pkexec); indicator and popout follow the profile names — `powersave` → `power-saver`, `Auto (reset)` → `balanced`. Same switch in `moonarch-cpugov` and `moonarch-waybar-cpugov`, the latter now reading the profile instead of `scaling_governor`, which under amd-pstate says nothing about it. `power-profiles-daemon` moves from `aur.txt` to `official.txt` (it is in `extra`), and the service list in `post-install.sh` and `moonarch-doctor` names it instead.
 
+## 2026-08-21 – stasis gets a desktop plan, not just ac/battery
+
+- **Who**: Dominik, ClaudeCode
+- **Why**: On a machine without a battery the screen never blanked and never locked — stasis sat at "waiting for idle" forever. Cause is in stasis, not in the timeouts: `detect_chassis()` returning `Desktop` selects `PlanSource::Desktop` (`src/daemon/mod.rs:76-85`), and that plan is built from the blocks directly under `default:` with the `ac:`/`battery:` containers explicitly excluded (`src/config/mod.rs:180-183` + `:230-233`). Our config had every step inside those two containers, so the desktop plan came out empty. `select_plan_source` only ever falls back *onto* the desktop plan, never from it onto `ac:` (`src/core/config.rs:288-306`), and the last-resort `rebuild_plan_default_order()` builds from `cfg.startup`/`brightness`/`dpms`/`suspend`/`lock_screen`, which the same parser had just set to `disabled()` (`src/config/mod.rs:173-177`) — a plan of disabled steps.
+- **Tradeoffs**: The desktop plan gets only two of the four steps. `brightness` is out because `brightnessctl` drives an internal panel and external monitors need DDC/CI, which it does not speak. `suspend` is out because suspending a desktop is a separate decision from idle screen handling, not something to inherit silently from the laptop plan. Timeouts are copied from the `ac:` plan so a docked laptop and a desktop behave the same. Duplicating those two blocks was accepted over restructuring the config: stasis offers no include or anchor mechanism, so the alternative would be moving all steps up to `default:` and overriding per container, which makes the laptop plans harder to read for no gain.
+- **How**: `dpms:` (120s, `niri msg action power-off-monitors` / `power-on-monitors`) and `lock_screen:` (180s, `swaylock -f`) added directly under `default:` in `defaults/xdg/stasis/stasis.rune`, with a comment recording why they sit there and not in a container.
+
 ## 2026-08-18 – swaylock config moves to /etc/swaylock, background is pre-blurred
 - **Who**: Dominik, ClaudeCode
 - **Why**: A second machine showed no lock screen background. The config was installed to `/etc/xdg/swaylock/config`, which swaylock never reads (only `~/.swaylock/config`, `$XDG_CONFIG_HOME/swaylock/config`, `SYSCONFDIR/swaylock/config`), and was made effective by seeding it into user homes from `post-install.sh` and the `.install` hook. Both seeds are conditional — the hook fires only on a moonarch-git install/upgrade and only under `[ ! -f ]` — so a machine that pulled no update since swaylock arrived (2026-08-14) ran with no config at all. Verified by running swaylock against a throwaway `HOME`: it rejects an invalid option from `~/.config/swaylock/config` before connecting to the compositor, and reports nothing when the same file sits in `/etc/xdg/`. The machine this was investigated on had the same gap unnoticed — its home copy had been renamed to `config.bak`, so neither machine was actually reading a config. Second request: the background should be blurred.

defaults/xdg/stasis/stasis.rune

@@ -34,6 +34,33 @@ default:
   lid_close_action "swaylock -f"
   lid_open_action  ""
 
+  # Desktop plan (machines without a battery)
+  #
+  # These blocks sit directly under `default:` on purpose: stasis builds the
+  # desktop plan from exactly those, with the ac:/battery: containers excluded
+  # (src/config/mod.rs, parse_plan_block "default"). A machine whose chassis
+  # reports no battery gets PlanSource::Desktop, and select_plan_source only
+  # ever falls back *onto* the desktop plan, never from it onto ac: -- so with
+  # the action blocks living in ac:/battery: alone, a desktop ran a plan of
+  # disabled steps: no DPMS, no lock, "waiting for idle" forever.
+  #
+  # Timeouts match the ac: plan below, so a docked laptop and a desktop behave
+  # alike. Deliberately only two steps:
+  #   brightness -- brightnessctl drives an internal panel; external monitors
+  #                 need DDC/CI, which it does not speak.
+  #   suspend    -- suspending a desktop is a separate decision, not part of
+  #                 idle screen handling.
+  dpms:
+    timeout 120
+    command "niri msg action power-off-monitors"
+    resume_command "niri msg action power-on-monitors"
+  end
+
+  lock_screen:
+    timeout 180
+    command "swaylock -f"
+  end
+
   # AC power plan (relaxed)
   ac:
     brightness: