## What happens

Clicking a monitor row in the Display bar panel does nothing. The row is not
greyed out, the pointer turns into a hand, the checkmark stays where it was,
and both monitors remain enabled. There is no error anywhere in the UI.

## Why

`toggleDisplay()` shells out to `hyprctl keyword`:

https://github.com/basecamp/omarchy/blob/main/shell/plugins/panels/monitor/Panel.qml#L303

```qml
actionProc.command = ["hyprctl", "keyword", "monitor", name + (enabled ? ",disable" : ",preferred,auto,auto")]
```

Hyprland refuses `keyword` when the config is parsed by the Lua parser, which
is what Omarchy ships:

```console
$ hyprctl keyword monitor "DP-5,disable"
keyword can't work with non-legacy parsers. Use eval.
$ echo $?
0
```

It exits **0**, so `actionProc` sees a clean run and the panel never learns
that nothing happened. Monitor state is unchanged:

```console
$ hyprctl monitors all -j | jq -r '.[] | "\(.name) disabled=\(.disabled)"'
eDP-1 disabled=false
DP-5 disabled=false
```

In the shipped 4.0.3 tree this is the only `hyprctl keyword` call left under
`shell/` and `bin/` — everything else already uses `eval` (e.g.
`enable_internal_output()` in `bin/omarchy-hyprland-monitor-clamshell`), so
this looks like the one spot missed in that migration.

## Steps to reproduce

1. Attach an external monitor (two enabled outputs, so the rows are clickable).
2. Open the Display panel from the bar.
3. Click the external monitor's row.
4. Nothing happens. `hyprctl monitors all -j` confirms `disabled` is unchanged.

## Expected

The clicked output is disabled, and clicking it again restores it to whatever
the user's `monitors.lua` specifies.

## Two further problems in the same function, found while testing the fix

Swapping `keyword` for `eval` is necessary but not sufficient — the re-enable
arm has two more defects. All four commands below were run on the affected
machine:

**1. Re-enabling needs an explicit `disabled = false`.** A `hl.monitor()` rule
that merely supplies a mode does not clear a previous `disabled = true`; the
call answers `ok` and the output stays off.

```console
$ hyprctl eval 'hl.monitor({ output = "DP-5", disabled = true })'
ok
→ DP-5 disabled=true                                    # the disable works

$ hyprctl eval 'hl.monitor({ output = "DP-5", mode = "preferred", position = "auto", scale = "auto" })'
ok
→ DP-5 disabled=true                                    # still off, silently

$ hyprctl eval 'hl.monitor({ output = "DP-5", disabled = false, mode = "preferred", position = "auto", scale = "auto" })'
ok
→ DP-5 disabled=false                                   # only this re-enables
```

**2. `preferred,auto,auto` discards the user's configured geometry.** My
`monitors.lua` pins that output to `scale = 1.25` at `0x0`. Re-enabling it the
way the panel does brings it back at a different scale and position:

```console
before:            DP-5 3840x2160@30 scale=1.25 pos=0x0     # as configured
after auto/auto:   DP-5 3840x2160@30 scale=1.5  pos=5120x0  # wrong
after hyprctl reload: DP-5 3840x2160@30 scale=1.25 pos=0x0  # correct again
```

So the disable arm wants `eval`, and the enable arm is better served by
`hyprctl reload`, which re-applies the user's own config instead of guessing at
it. That also matches what `omarchy-hyprland-monitor-internal` already does for
the laptop panel: write/remove a toggle under
`~/.local/state/omarchy/toggles/hypr/` and reload.

Happy to open a PR along those lines if that is the direction you want.

## System

| | |
|---|---|
| Omarchy | 4.0.3-1 |
| Hyprland | 0.56.2 (`efb5099`) |
| Quickshell | 0.3.1 (Arch) |
| Kernel | 7.2.4-arch1-Watanare-T2-1-t2 |
| CPU | Intel Core i7-9750H |
| GPU | Intel UHD 630 + AMD Radeon Pro 5500M |
| Outputs | eDP-1 (internal) + DP-5 (BenQ PD2700U, DisplayPort) |

Reproduced against `main` as well: `shell/plugins/panels/monitor/Panel.qml`
line 303 is unchanged there at the time of filing.