### System details

12th Gen Intel i7-12700H, Intel Iris Xe + NVIDIA RTX 3070 Mobile, Omarchy 4.0.2-1, systemd 261

### What's wrong?

## What's wrong?

`omarchy-update-stay-awake` blocks sleep for the duration of an update:

```bash
# bin/omarchy-update-stay-awake:104 and :111 (master @ 4930677)
systemd-inhibit \
  --what=sleep:idle \
  --who=omarchy-update \
  --why="Omarchy update in progress" \
  --mode=block \
  sleep infinity
```

`sleep` and `idle` are both *high-level* inhibitor locks, and logind ignores those for the lid switch by default. From `logind.conf(5)`, on `LidSwitchIgnoreInhibited=`:

> Controls whether actions that systemd-logind takes when the power, reboot and sleep keys and the lid switch are triggered are subject to high-level inhibitor locks ("shutdown", "reboot", "sleep", "idle"). Low level inhibitor locks ("handle-power-key", "handle-suspend-key", "handle-hibernate-key", "handle-lid-switch", "handle-reboot-key"), are always honored, irrespective of this setting.
>
> [...] `LidSwitchIgnoreInhibited=` defaults to "yes". This means [...] the lid switch does not respect suspend blockers by default.

Omarchy ships two logind drop-ins in `etc/systemd/logind.conf.d/` (`10-ignore-power-button.conf` and `20-inhibit-delay.conf`), and neither sets `LidSwitchIgnoreInhibited`, so the default `yes` applies.

So closing the laptop lid during `omarchy update` should suspend the machine anyway, despite the inhibitor that exists to prevent exactly that. Worst case it interrupts a pacman transaction.

### Steps to reproduce

1. On a laptop, start `omarchy update`.
2. Confirm the inhibitor is registered: `systemd-inhibit --list` shows `omarchy-update ... sleep:idle ... block`.
3. Close the lid.
4. The machine suspends despite the block inhibitor.

### Suggested fix

Add the low-level lock, which `logind.conf(5)` says is always honored regardless of the setting:

```diff
-  --what=sleep:idle \
+  --what=sleep:idle:handle-lid-switch \
```

That is narrower than the alternative of shipping a drop-in with `LidSwitchIgnoreInhibited=no`, since it changes this one inhibitor rather than lid policy for every application on the system.

### Scope note

I verified steps 1 and 2 and the configuration state. I have not observed step 4 on a live update, because deliberately interrupting a pacman transaction was not something I wanted to do on my own machine. The rest is inferred from `logind.conf(5)` and from the absence of any `LidSwitchIgnoreInhibited` setting in the repo. I can confirm on a throwaway install if that would help.