## System details

- Omarchy: 4.0.1 (was 4.0.0 when the bug hit; arrived there via the omarchy-dev → 4.0.0 release migration)
- CPU: 13th Gen Intel Core i5-1335U (ThinkPad E16)
- GPU: Intel Raptor Lake-P Iris Xe
- kernel-modules-hook 0.1.7-3 (installed via `omarchy-base.packages`)

## What happened

`omarchy update` aborted with **6,454** raw pacman errors, all of the form:

```
error: failed to commit transaction (conflicting files)
linux: /usr/lib/modules/7.1.9-arch1-2/... exists in filesystem
```

Every conflicting path was inside `/usr/lib/modules/7.1.9-arch1-2/`, which existed on disk but was owned by no package. The update died before any transaction started, with no guidance beyond the generic "Something went wrong during the update!" trap message.

## Root cause

This is an interaction between the release migration's kernel **downgrade** and `kernel-modules-hook` (which Omarchy installs in the base package set):

1. Machine was on the omarchy-dev channel with `linux 7.1.9.arch1-2` installed **and booted**.
2. The omarchy-dev → 4.0.0 release migration synced back to the stable repo state, which at that moment meant `downgraded linux (7.1.9.arch1-2 -> 7.1.8.arch1-3)` (from `pacman.log`).
3. kernel-modules-hook did its job: its `10-linux-modules-post` hook rsync'd the *running* kernel's (7.1.9) modules back into `/usr/lib/modules/` so the live system kept working — leaving the whole 7.1.9 tree **unowned by any package**.
4. The user (me) didn't reboot.
5. Arch later re-released `linux 7.1.9.arch1-2`. The next `omarchy update` tries to upgrade 7.1.8 → 7.1.9 and pacman refuses: every package file collides with the unowned hook-restored copy.

Two properties make this a persistent wedge rather than a self-healing hiccup:

- pacman's file-conflict check runs **before** PreTransaction hooks, so `10-linux-modules-pre` never gets a chance to move the directory out of the way.
- kernel-modules-hook's `linux-modules-cleanup.service` explicitly **skips the running kernel's tree**, so as long as you stay booted into 7.1.9, nothing ever cleans it up, and every `omarchy update` fails the same way. (`omarchy update` only passes `--overwrite '/usr/share/omarchy/*'`, which doesn't cover it.)

## Steps to reproduce

1. Be booted into kernel version X with kernel-modules-hook installed.
2. Downgrade `linux` to an older version (the dev → 4.0.0 release migration did this implicitly) — the hook restores X's modules as unowned files.
3. Without rebooting, wait for the repo to offer version X again and run `omarchy update`.
4. Update fails with thousands of "exists in filesystem" conflicts.

## Expected

Either the update handles the conflict (the on-disk files are byte-identical to the package's — I verified with `diff -rq` against the cached `linux-7.1.9.arch1-2` package before overwriting), or the failure message tells the user what's going on instead of dumping ~6,500 raw pacman lines.

## Workarounds that fix it

- `sudo pacman -S linux --overwrite '/usr/lib/modules/<running-kver>/*'`, then rerun `omarchy update` (what I did — clean result, package took ownership of identical files), or
- reboot first (into the installed older kernel), which lets `linux-modules-cleanup.service` sweep the now-not-running unowned tree, then update.

## Suggested fix

In `omarchy-update-system-pkgs`, when the upgrade fails and the conflicts are confined to `/usr/lib/modules/$(uname -r)/` with that directory unowned (`pacman -Qo` fails) and the `linux` upgrade target matches the running kernel version, retry with `--overwrite "/usr/lib/modules/$(uname -r)/*"` — or at minimum detect the pattern and print "reboot, then update again" instead of the raw pacman spew. Could also be handled in the migration that performs the downgrade.

Happy to PR the detection/retry if you'd take it.