### System details

- Omarchy: 4.0.0-1 (stable)
- Kernel: 7.1.8-arch1-3
- CPU: Intel Core i5-7300HQ
- GPU: Intel HD Graphics 630 + NVIDIA GeForce GTX 1050 Mobile

### What's wrong?

After an `omarchy update` that touches AUR packages, later `omarchy update` runs abort immediately with:

```
An Omarchy update is already running.
```

even though nothing is updating. The flock is still held by a daemon spawned during the previous update.

On this machine the leftover holder was `adb`, started from a `flutter-beta` AUR build:

```
$ fuser -v $XDG_RUNTIME_DIR/omarchy-update.lock
                     USER        PID ACCESS COMMAND
/run/user/1000/omarchy-update.lock:
                     linuxbox  139567 F.... adb

$ ls -l /proc/139567/fd/10
/proc/139567/fd/10 -> /run/user/1000/omarchy-update.lock

$ tr '\0' ' ' < /proc/139567/cmdline; echo
adb -L tcp:5037 fork-server server --reply-fd 4

$ readlink /proc/139567/cwd
/home/linuxbox/.cache/yay/flutter-beta/src/flutter

$ ps -o pid,ppid,lstart,cmd -p 139567
# PPID is user systemd; the update that spawned it is long gone
```

`omarchy-update-lock` opens the lock without `O_CLOEXEC` and `exec`s the update:

```bash
exec {OMARCHY_UPDATE_LOCK_FD}>"$lock_path"
flock -n "$OMARCHY_UPDATE_LOCK_FD"
export OMARCHY_UPDATE_LOCK_FD
exec "$@"
```

Every child inherits that fd. `omarchy-update-aur-pkgs` runs `yay -Sua`, and packages such as Flutter start `adb` which daemonizes onto user systemd and keeps the fd open after the update exits. The next `omarchy-update-lock run` then fails the non-blocking flock.

This is the same leak `omarchy-update-stay-awake` already special-cases for `systemd-inhibit` (`{OMARCHY_UPDATE_LOCK_FD}>&-`), and `docs/update-process.md` already documents why:

> That inhibitor outlives the step that starts it, so an update killed before cleanup would otherwise leave it holding the flock indefinitely — blocking later updates

AUR/yay children are the same class of process and do not get that close.

#### Steps to reproduce

1. Have an AUR package installed whose build or post-install starts a long-lived daemon that does not close extra fds (Flutter/`adb` is a reliable one).
2. Run `omarchy update` far enough for `omarchy-update-aur-pkgs` / `yay -Sua` to run.
3. Let the update finish (or abort after that step). Confirm no `omarchy-update` process remains.
4. Run `omarchy update` again.

#### Expected behavior

The lock is released when the `omarchy update` process tree exits. A later update can start.

#### Actual behavior

`An Omarchy update is already running.` The lock file is held by the leftover daemon (`adb` here). Removing the lock path (`rm -f "$XDG_RUNTIME_DIR/omarchy-update.lock"`) unblocks the next run because the next open creates a new inode; killing the daemon also works.

#### Suggested fix

Do not let children inherit the lock fd. Two options that keep the current "parent holds the flock" model:

1. After `omarchy-update-lock held` succeeds, set `FD_CLOEXEC` on `OMARCHY_UPDATE_LOCK_FD` so later `yay`/`adb`/`systemd-inhibit` children cannot keep it. `held` still works in the update process itself because it inspects `/proc/$$/fd`.
2. Stop `exec`ing the update into the lock-holder. Have `omarchy-update-lock run` keep the flock in the parent and spawn the update with the fd closed (`{OMARCHY_UPDATE_LOCK_FD}>&-`), using an env flag instead of `held` to avoid re-acquire. That is what `flock --close` is for.

Option 2 matches the stay-awake comment in `docs/update-process.md` and does not depend on every child remembering to close the fd.

#### Workaround

```bash
rm -f "${XDG_RUNTIME_DIR}/omarchy-update.lock"
```