Add a refresh rate section to the Display panel

[langri-sha]

The Display panel can already change scale, but not the rate the screen runs at. Plenty of hardware doesn't come up at the rate it's sold as — a 144Hz laptop panel that boots at 60Hz, or a screen that drops down on battery — and the fix today is hand-editing monitors.lua and reloading.

This adds a Refresh rate row beneath Scale, listing the rates the focused display's current mode can reach. It behaves like the scale presets: pills in a row, h/l to walk them, click or Return to apply, and the active pill carries the current rate — no second readout beside the header, for the same reason SCALE doesn't have one. A display with only one rate isn't offering a choice, so the section doesn't render at all.

That's the panel running on a 1920x1200 laptop panel that advertises both 144Hz and 60Hz, sitting at 60.

Pieces

• omarchy-hyprland-monitor-refresh-rate — shows the focused monitor's rate, or switches it. It only accepts a rate the current resolution already offers, so a bad request is refused rather than handed to Hyprland to resolve into a fallback mode.
• omarchy-monitor-state now reports each display's live rate and the modes at its own resolution. Modes at other resolutions are dropped: those are resolution changes, not rates.
• Model.js gained the rate helpers, so the parsing and matching are unit-tested alongside the scale ones.

Two details worth flagging

Rates are matched, not compared. Hyprland lists a mode as 143.91Hz while reporting the driver's live rate as 143.912, so a request snaps to the nearest listed mode within half a hertz and the active pill is chosen the same way. Pills are labelled by whole hertz — the number the display is sold as — and two modes that round to the same label (59.94 and 60) collapse to the faster one.

Refresh rate is deliberately not persisted to monitors.lua. Scaling can be, because the default config carries one scale for every output. A refresh rate belongs to a single monitor's mode, and writing it into that same catch-all would force one display's rate on all of them. The manual explains how to pin a rate with a per-output hl.monitor entry instead. Happy to wire up persistence if you'd rather it survived a reboot — it'd want a per-output block in monitors.lua, which is a bigger change than this.

Verification

./test/all passes. New coverage in test/shell.d/monitor-refresh-rate-test.sh (the CLI: reading, snapping, scale preservation, refusing an out-of-mode rate, refusing an unsafe output name) plus rate helpers in monitor-test.sh and the new state fields in monitor-state-test.sh. qmllint is clean on the panel.

The CLI was exercised against real Hyprland on the display above: reading the live rate, refusing 100Hz, switching 60 → 144 and back, with scale held at 1.25 across both changes. Worth noting that after switching, the driver reports 144.00101 for a mode listed as 144.00Hz — the half-hertz match resolves that to the right pill, which is exactly why it isn't an equality check.

The screenshot is the panel itself, rendered from this branch in a real Quickshell instance the way test/shell.d/runtime-smoke-test.sh launches one, reading live hyprctl state.