## What happens

On some laptops the firmware's ACPI `_LID` method gets stuck reporting `closed` while the lid is open. When that happens, plugging in an external monitor blanks the internal panel: `omarchy-hyprland-monitor-clamshell` sees "lid closed + external active", writes the clamshell toggle, and disables eDP-1. Unplugging re-enables it, so the symptom looks like "my laptop screen dies whenever I connect my monitor". Workspaces also migrate to the external and back on each cycle, which adds to the confusion.

I hit this on a Razer Blade Stealth 13 (Late 2019). The desync is intermittent. In my captured case ACPI reported `closed` for over an hour of lid-open use, then recovered on its own:

```
$ cat /proc/acpi/button/lid/LID0/state
state:      closed                                # lid physically open

$ busctl get-property org.freedesktop.login1 /org/freedesktop/login1 \
    org.freedesktop.login1.Manager LidClosed
b false                                           # logind, correct

$ journalctl -b | grep -i "lid"
Sep 01 21:21:43 omarchy systemd-logind[744]: Lid opened.   # last real event
```

Hyprland's log at hotplug time shows the resulting disable:

```
drm: Modesetting DP-3 with [email protected]
drm: Disabling output eDP-1
drm: Connector eDP-1 enabledState changed true -> false
```

## Why

`omarchy-hw-laptop-closed` reads only `/proc/acpi/button/lid/*/state`. logind and libinput both derive lid state from the evdev `SW_LID` switch instead, with logind adding hardware quirk handling on top, which is why logind had the right answer the whole time. Omarchy already treats logind as the authority on lid policy elsewhere: it keeps logind's `HandleLidSwitch` defaults untouched, and `omarchy-system-lid-close`'s docked/undocked reasoning is written against logind's behavior. The detection script is the one place that trusts raw firmware state instead.

## Fix

Ask logind first, keep ACPI as the fallback:

- `busctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager LidClosed`, and parse `b true`/`b false`.
- If busctl produces nothing (no running logind, e.g. installation chroots), fall back to the existing ACPI loop unchanged.

Pure bash, no new dependencies (busctl ships with systemd). PR incoming with a test that pins both branches.

## Blast radius

`omarchy-hw-laptop-closed` has five non-test call sites, so the change affects more than clamshell:

- `bin/omarchy-hw-clamshell` and `bin/omarchy-system-lid-close`: the display/lock paths this fixes.
- The PAM fingerprint gate (`auth [success=1 default=ignore] pam_exec.so quiet /usr/bin/omarchy-hw-laptop-closed` in `/etc/pam.d/sudo` and `/etc/pam.d/polkit-1`): runs as root at auth time. busctl talks to the system bus by default, so it works there; when D-Bus itself is unreachable the ACPI fallback answers, same as today.
- `shell/plugins/polkit/PolkitAgent.qml`: samples the command per auth request. Behavior unchanged apart from correctness.

The stuck-ACPI failure mode currently affects those consumers too: with ACPI stuck on `closed`, fingerprint auth is silently skipped on an open laptop, and the polkit dialog hides the fingerprint prompt. The fix corrects all of them at once.