### System details

- Framework Laptop 13 (AMD Ryzen AI 9 HX 370 / Radeon 890M, amdgpu), BIOS INSYDE 03.05
- Omarchy 4.0.0-1, Hyprland 0.56.2, kernel 7.1.8-arch1-3, s2idle
- External display: Dell U2723QE on `DP-5` behind a CalDigit TS3 Plus (Intel JHL6540 Alpine Ridge, TBT3)
- Clamshell: lid closed, `eDP-1` disabled by `omarchy-hyprland-monitor-clamshell`

### What's wrong?

After a long suspend in clamshell mode the external monitor never lights up again. The session itself is fine — input reaches the compositor, the idle monitor logs activity, `hyprctl` answers — but the panel stays in standby until the lid is opened or the machine is rebooted. Short suspends always come back.

### Root cause

The display comes back only when something re-probes the connector, and after a long s2idle nothing does.

1. On every resume amdgpu discards the hotplug interrupts raised inside the resume window: `[drm] Skip DMUB HPD IRQ callback in suspend/resume`.
2. Re-detection therefore depends on the dock re-asserting HPD *after* resume — `[drm] DMUB HPD RX IRQ callback: link_index=5`, normally 1–6 s after `PM: suspend exit`. That event is what makes aquamarine rescan and re-modeset.
3. After a long sleep the Thunderbolt tunnel does not fully return, and that HPD never arrives. The kernel keeps the stale pre-suspend `connected` state, so nothing looks wrong from userspace, and the compositor keeps driving a monitor that is asleep.

Every cycle from my journals, same machine, same dock:

| Sleep length | Wake | `HPD RX` after `suspend exit` | Result |
|---|---|---|---|
| 10 s | keypress | +0.0 s, +5.5 s | display returns |
| 1.2 min | keypress | +1.3 s | display returns |
| 11.7 min | keypress | +5.6 s | display returns |
| **39.8 min** | **keypress, lid stayed closed** | **none** | **black until reboot** |
| 3 h 24 min | lid opened | +5.6 s | returns, but only because the lid HPD forced the rescan |

Correlated kernel noise on the same resumes, worse the longer the sleep:

```
pcieport 0000:02:00.0: Data Link Layer Link Active not set in 100 msec
pcieport 0000:02:01.0: Data Link Layer Link Active not set in 100 msec
xhci_hcd 0000:03:00.0: Controller not ready at resume -19
xhci_hcd 0000:03:00.0: PCI post-resume error -19!
xhci_hcd 0000:03:00.0: HC died; cleaning up
```

Opening the lid recovers because the eDP hotplug triggers a full connector rescan, which re-modesets `DP-5` as a side effect.

### Steps to reproduce

1. Clamshell: lid closed, single external monitor over a TB3/USB4 dock, internal panel disabled.
2. Suspend and leave the machine asleep for ~40 minutes or more.
3. Wake it with the external keyboard, lid still closed.
4. The machine resumes — the monitor does not.

### Not Hyprland

aquamarine does re-modeset enabled outputs on session resume, but only for connectors the kernel reports as connected, and the kernel's cached state is stale rather than absent. `hyprctl reload` (what `omarchy-hyprland-monitor-modeless` falls back to) does not help either: the compositor is not the component holding the wrong state.

### What does fix it

Forcing the kernel to re-detect, which needs root:

```bash
echo off    > /sys/class/drm/card1/card1-DP-5/status
sleep 1
echo on     > /sys/class/drm/card1/card1-DP-5/status
echo detect > /sys/class/drm/card1/card1-DP-5/status
```

The monitor is back within a second. `echo detect` on its own is a no-op — the cached status does not change, so no uevent is emitted and nothing re-modesets. This is the same gap `omarchy-hyprland-monitor-watch` already comments on ("forcing a re-probe needs root").

PR with a sleep hook that does this automatically — and only when no DRM hotplug arrived with the resume — follows.

Possibly the same underlying report as #3511, though that one is about the machine not resuming at all rather than resuming dark.