docs(niri): the ultrawide's refresh ceiling was a typo, not a limit

The page asserted the Sceptre M34's EDID tops out at 180 Hz. Measured on blankpad
after the merge, `niri msg outputs` lists 3440x1440@239.998 — the claim was false
in main, and it was load-bearing: it is the reason nobody questioned the profile
while the panel ran at 60 Hz for weeks. The real defect was one character: the
profile asked for 239.999, the panel offers 239.998, and niri matches mode strings
verbatim, falling back to *preferred* without failing.

Corrected to the measured mode list, and the deployed 180 is now documented as a
deliberate choice (the link is trained at x8 32.0 GT/s against a max of x16 and the
display engine throws EINVAL), so the next reader neither "restores 240" blind nor
re-pins 180 as a hardware ceiling. The kdl profile comment carries the same facts at
the point of edit, because that is where the next change to this mode gets typed.

Refs #60

dotfiles/zz-blankpad/niri/.config/niri/cfg/desk-1-home.kdl

@@ -7,10 +7,14 @@
 // requires: Lenovo Group Limited 0x40A9 Unknown
 // optional: HDMI-A-1 (PM1601, dock-dependent)
 
-// This panel's EDID tops out at 3440x1440@180 (read live from niri: no 240 Hz mode
-// exists). Ask for a mode the panel does not offer and niri does not fail — it logs
-// "could not be found, falling back to preferred" and drops to 60 Hz on every
-// reconnect. Keep 180 here unless a re-read EDID says otherwise.
+// The panel offers 3440x1440@239.998 as well as @180.000 (`niri msg outputs`, 2026-10-21), and
+// 180 is driven DELIBERATELY: the link trained at x8 32.0 GT/s against a max of x16 and the
+// display engine is throwing DMCUB errors with EINVAL page flips after s2idle, so the 240-class
+// mode stays undriven until a reboot clears that state. niri matches mode strings VERBATIM and
+// does not round: "@239.999" is not "@239.998", and a mode it cannot find does not fail — it
+// logs "could not be found, falling back to preferred" and drops the panel to 60 Hz on every
+// reconnect, which is how this desk ran for weeks. Copy the string from `niri msg outputs`.
+// Reasoning and triage: omp-docs/tools/niri/displays.md ("The config pattern", rules 4 and 5).
 output "Sceptre Tech Inc Sceptre M34 Unknown" {
     mode "3440x1440@180.000"
     scale 1

omp-docs/tools/niri/displays.md

@@ -41,17 +41,19 @@ list it as an installed tool are stale.
 │  1200x1920   │   landscape, scale 1         │ scale 1  │
 │  rot 90      │   position 1581,-600         │ 5021,-240│
 └──────────────┴──────────────────────────────┴──────────┘
-  HDMI-A-1            DP-2 (focus-at-startup)     eDP-1 (fallback focus)
+  HDMI-A-1            DP-1 (focus-at-startup)     eDP-1 (fallback focus)
+Connector names are today's (`niri msg outputs`, 2026-10-21). They reshuffle with
+the dock and the cable, which is why the config keys on the EDID long name instead.
 ```
 
 | Panel | EDID long name | Keyed by | Notes |
 |-------|----------------|----------|-------|
-| Sceptre M34 ultrawide | `Sceptre Tech Inc Sceptre M34 Unknown` | identity | `mode "3440x1440@180.000"` — the EDID maximum; no 240 Hz mode exists — `focus-at-startup` |
+| Sceptre M34 ultrawide | `Sceptre Tech Inc Sceptre M34 Unknown` | identity | `mode "3440x1440@180.000"`, **deliberate** — the panel also offers `3440x1440@239.998`, `144.001` and `120.000`; 180 is driven while the link is degraded (see the law below) — `focus-at-startup` |
 | PM1601 portrait | *not captured* | connector `HDMI-A-1` | dock-dependent; run `desk.sh capture` when plugged in, then re-key |
 | eDP-1 laptop panel | `Lenovo Group Limited 0x40A9 Unknown` | identity | scale **1.0** (deliberate; Ghostty grid at 1.25 rejected 2026-10-09), second `focus-at-startup` |
 
-VRR: DP-2 supports it; **left disabled by decision** (2026-10-09). Add
-`variable-refresh-rate` per output if that ever changes.
+VRR: the M34 supports it (its connector today is `DP-1`); **left disabled by
+decision** (2026-10-09). Add `variable-refresh-rate` per output if that ever changes.
 
 `focus-at-startup` on both M34 and eDP-1: niri focuses in config order, so
 the ultrawide wins when present and the laptop panel is the fallback.
@@ -113,12 +115,22 @@ Four rules learned the hard way:
 3. **Positions are absolute, not relational.** A disconnected panel leaves
    a hole; that is exactly why positions belong to the *desk profile*, not a
    global file.
-4. **Ask only for modes the panel reports** (`niri msg outputs` → `Mode:` list).
-   A mode the panel never offered does **not** leave the output dark: niri logs
-   `configured mode … could not be found, falling back to preferred` and quietly
-   drives the panel at its EDID *preferred* mode — **60 Hz** on the M34. Nothing
-   looks broken except the refresh rate, and every reconnect repeats the
-   fallback. Check Hz, not just resolution, after any "monitor is acting up".
+4. **Ask only for modes the panel reports, and copy the string exactly.** The M34's
+   `Available modes` (`niri msg outputs`, 2026-10-21) are `3440x1440@239.998`,
+   `3440x1440@180.000`, `144.001`, `120.000`, … with `59.998` marked preferred. niri
+   matches mode strings **verbatim** and does not round, so `239.999` — one digit from
+   the real mode, which is what this file and the config both carried for weeks — is not
+   `239.998`. A mode it cannot find does **not** leave the output dark: niri logs
+   `configured mode … could not be found, falling back to preferred` and quietly drives
+   the panel at its EDID *preferred* mode — **60 Hz**. Nothing looks broken except the
+   refresh rate, and every reconnect repeats the fallback. Check Hz, not just
+   resolution, after any "monitor is acting up".
+5. **180 Hz here is a decision, not a ceiling.** The panel offers 239.998 and is driven
+   at 180.000 deliberately: the link trained at `x8 32.0 GT/s` against a max of `x16`,
+   and the display engine is throwing `DMCUB` errors with `EINVAL` page flips after
+   s2idle, so the 240-class mode is not driven until a reboot clears that state. Before
+   changing the mode, re-read `niri msg outputs` **and** the link sysfs; treat "restore
+   240" as a change to verify on a healthy link, never as the obvious fix. Refs #60.
 
 ## "The monitors are broken" — three layers, three signatures