## What happened

On resume from suspend, and continuously while moving the mouse on the lock screen, the internal display's scale flickers between the correct value (1) and 2 — the whole shell (bar, text, lock screen UI) briefly jumps to double size and then snaps back. After unlocking it happens once more and then stays stable.

## Expected

The internal display should stay at its configured scale; no scale should ever be force-applied unless it actually needs correcting.

## Root cause

`omarchy-hyprland-monitor-clamshell` is invoked on every "wake" (including from `LockView.qml`'s `MouseArea.onPositionChanged` on the lock screen, via `omarchy-system-wake`). Its `enable_internal` → `sync_internal_scale` path decides whether to re-apply a scale by comparing the *active* scale against a *desired* scale read from `~/.config/hypr/monitors.lua`:

```sh
monitor_rule_regex() {
  printf '^[[:space:]]*hl\\.monitor\\(\\{.*output[[:space:]]*=[[:space:]]*"%s"' "$1"
}
```

`configured_internal_monitor_value` calls this with `$INTERNAL` = the literal port name from `omarchy-hyprland-monitor-laptop` (e.g. `eDP-1`). This only matches a rule written as `output = "eDP-1"`. It does **not** match a rule that identifies the same output by description, e.g.:

```lua
hl.monitor({
  output = "desc:LG Display 0x0742",
  mode = "[email protected]",
  scale = 1,
  ...
})
```

`desc:`-based output selectors are a normal, documented way to address a monitor in Hyprland (useful because port names can change across kernels/docks), and are what third-party monitor-profile tools (e.g. `hyprmoncfg`) generate by default.

When the regex fails to match, `configured_monitor_scale` returns empty. `read_monitor_scale` then falls back to a saved state file (`~/.local/state/omarchy/toggles/hypr/internal-monitor-scale`), and if that's also absent, hardcodes a default of `2`:

```sh
read_monitor_scale() {
  local scale
  scale=$(configured_monitor_scale)
  if valid_scale "$scale"; then echo "$scale"; return; fi
  if [[ -f $SCALE_STATE ]]; then
    scale=$(<"$SCALE_STATE")
    if valid_scale "$scale"; then echo "$scale"; return; fi
  fi
  echo 2
}
```

On a non-HiDPI internal panel configured at `scale = 1` via a `desc:` rule, this fallback is wrong. `sync_internal_scale` then sees a mismatch against the real active scale (1) and force-applies `scale = 2` via `hyprctl eval`, causing the visible flash. A separate monitor-profile daemon (in my case `hyprmoncfgd`) then corrects it back on its own poll cycle, producing the flicker. Because the lock screen fires `wakeRequested()` (and thus this whole chain) on *every* mouse-move event, the flicker repeats continuously while the mouse moves on the lock screen, and fires once more on unlock.

## Steps to reproduce

1. Configure the internal monitor in `~/.config/hypr/monitors.lua` using a `desc:`-based `output` selector at `scale = 1` (e.g. via `hyprmoncfg`, or by hand).
2. Make sure `~/.local/state/omarchy/toggles/hypr/internal-monitor-scale` does not exist / does not hold the correct scale.
3. Lock the screen and move the mouse continuously, or resume from suspend.
4. Observe the shell repeatedly flash to double size and snap back.

## Suggested fix

`configured_internal_monitor_value` / `monitor_rule_regex` should also match the internal monitor when it's identified by `desc:<description>` (available via `hyprctl monitors -j` as `.description`), not only by literal port name. At minimum, `read_monitor_scale`'s hardcoded final fallback of `2` should not be force-applied without first confirming a mismatch actually needs correcting — right now a parse failure is indistinguishable from "the user wants 2x", and the function actively pushes that guess to the compositor instead of leaving the monitor alone when it can't determine the configured scale.

## Workaround

Manually seeding `~/.local/state/omarchy/toggles/hypr/internal-monitor-scale` with the correct scale (`1` in my case) makes `read_monitor_scale`'s second fallback succeed, so `sync_internal_scale` sees a match and never force-applies anything.

## System details

- Omarchy: 4.0.0-1
- Machine: Acer Nitro ANV15-51 (hybrid graphics)
- CPU: 13th Gen Intel Core i5-13420H
- Graphics: Intel Raptor Lake-P UHD (i915, active on eDP-1) + NVIDIA GeForce RTX 3050 6GB Laptop GPU (nvidia 610.57.04)
- Kernel: 7.1.8-arch1-3
- Hyprland: 0.56.2
- Monitor profile tool in use: `hyprmoncfg` 1.13.0 (AUR), which generates `monitors.lua` with `desc:`-based output selectors

## Unrelated bug noticed while gathering diagnostics

`omarchy debug --no-sudo --print` (and `omarchy debug` in general) currently fails with "Unknown Omarchy command: omarchy debug" even though it's listed as a common command in `omarchy --help`. The underlying binary `/usr/bin/omarchy-debug` works fine when invoked directly, so this looks like a dispatcher/registration regression. Happy to file this separately if preferred.