## Summary

While docked (laptop lid closed with an external monitor active), the internal panel (`eDP-1`) repeatedly flips disabled/enabled roughly every 1.5–3 seconds for as long as the lid stays closed. The same storm also fires from the manual "Toggle laptop display" keybind (`Super+Ctrl+Delete` → `omarchy-hyprland-monitor-internal toggle`), which is supposed to be a stable manual override but gets fought and overridden by the same background reconciliation logic — pressing it produces a burst of ~10 rapid disable/enable cycles and settles back to **enabled**, silently discarding the manual "off".

Effects observed during a storm:
- Screen glitching/lag (CRTC torn down and rebuilt on every reload)
- Corrupted/stuck keyboard input — each reload recompiles the xkb keymap, and the journal shows repeated `Key <LFSH> added to map for multiple modifiers` errors during storms
- Workspace 1/2 bouncing between monitors as the monitor set repeatedly changes
- Audible fan ramp-up from the repeated reload/modeset churn

## Environment

- Omarchy: 4.0.2-1 (upgraded from a pre-Quattro `.conf`-based install same day)
- Hyprland: 0.56.2 (v0.56.2, commit efb5099)
- Kernel: 7.1.9-arch1-2
- Laptop: Lenovo 20YU002PUS, Intel i7-11800H
- GPU: NVIDIA RTX A3000 Laptop GPU, driver 610.57.04 (proprietary, dGPU-only)
- Displays: internal `eDP-1` (3840x2160, scale 2) + external `DP-3` (Samsung Odyssey G9, 5120x1440@240 over DisplayPort)

## Steps to reproduce

1. Dock the laptop with the external monitor active (extended mode).
2. Close the laptop lid.
3. Watch `hyprctl monitors all -j` (or the panel itself) — `eDP-1.disabled` flips true/false continuously until the lid reopens.

Alternate trigger, no lid involved:

1. While docked with the lid open, press `Super+Ctrl+Delete` (default "Toggle laptop display" bind).
2. Instead of one clean disable, the panel flickers ~10 times in a couple of seconds and ends up back on. `~/.local/state/omarchy/toggles/hypr/internal-monitor-disable.lua` is not left in place afterward.

## Expected

- Lid close: `eDP-1` disables once, stays disabled until the lid reopens.
- Manual toggle: `eDP-1` disables once, stays disabled until toggled back on, independent of the background poll.

## Evidence

**The physical lid switch is clean** — `systemd-logind` logs exactly one transition each way:
```
Aug 31 09:17:05 archhelga systemd-logind[1811]: Lid closed.
Aug 31 09:17:49 archhelga systemd-logind[1811]: Lid opened.
```
`hyprland.log` shows dozens of disable/enable cycles inside that single 44s window (46 "disabled, releasing crtc" lines across the session).

**High-frequency live capture (0.15s polling) across a full lid-closed window, cross-checked against raw kernel state:**
```
09:28:28 -> 09:28:54 (lid closed the whole time):
  eDP-1 disabled: true(~1.5-3s) -> false(~150-300ms) -> true -> false -> ... (repeats ~13x)
09:28:54  systemd-logind: Lid opened.
  eDP-1 disabled: false, and stays false for the rest of the capture (168 straight samples)

Across all 300 samples in this capture:
  /sys/class/drm/card1-DP-3/status   -> "connected" every sample, 0 deviations
  /sys/class/drm/card1-eDP-1/status  -> "connected" every sample, 0 deviations
  DP-3 via `hyprctl monitors all -j` -> disabled:false, 5120x1440 every sample, 0 deviations
```
This rules out any actual hardware/DRM-level flakiness on the external monitor's connector — the oscillation is entirely internal to Hyprland's own state for `eDP-1`, and its ~2s period lines up with `omarchy-hyprland-monitor-watch`'s `poll_clamshell_state` backstop loop (`sleep 2; sync_clamshell`).

**`hyprland.log` excerpt from the manual-toggle storm** (same signature as the lid-close storm, ~10 cycles in a couple of seconds):
```
drm: Connector eDP-1 enabledState changed true -> false
drm: eDP-1 is disabled, releasing crtc 200
drm: Connector eDP-1 enabledState changed false -> true
... (repeats ~10x)
```

**Keyboard corruption during a storm** (journal, same window as the lid-close storm):
```
Aug 31 09:19:18 uwsm_hyprland.desktop: > Error: Key <LFSH> added to map for multiple modifiers
Aug 31 09:19:18 uwsm_hyprland.desktop: Errors from xkbcomp are not fatal to the X server
```
(repeats several times — nearly every reload during a storm retrips this pre-existing xkbcomp issue)

## Suspected mechanism

`omarchy-hyprland-monitor-watch` runs `poll_clamshell_state` (a 2s backstop loop) plus a cascade of delayed re-syncs (`sync_clamshell_after_monitor_change`, delays 1/3/7s) on every monitor add/remove event — and disabling/enabling `eDP-1` itself fires such an event, so each cycle can retrigger the next one. `omarchy-hyprland-monitor-clamshell`'s `enable_internal()` deletes the `internal-monitor-clamshell.lua` toggle flag every time it runs; if the branch condition (`omarchy-hw-clamshell && omarchy-hyprland-monitor-external-active`) is ever momentarily false, the very next `disable_internal()` call finds the flag missing and reissues a full `hyprctl reload` — the two functions appear to alternate. I confirmed via the capture above that this isn't a real external-monitor detection flap, so whatever is transiently flipping that condition lives elsewhere in the chain — I wasn't able to pin the exact line without instrumenting the packaged scripts directly.

The manual toggle (`omarchy-hyprland-monitor-internal off`) writes a *different* flag (`internal-monitor-disable.lua`, checked via `MANUAL_DISABLE_FLAG` in `enable_internal()`) that's meant to short-circuit the poll — but empirically it doesn't survive contact with it either.

Happy to provide the full log captures or run further live instrumentation if that would help narrow this down further.