## What happened

On a machine still on the legacy self-updating git-checkout Omarchy install (no `omarchy` pacman package, `~/.local/share/omarchy` a plain git clone, no `/usr/share/omarchy`), running `omarchy-update`/`omarchy-migrate` hit two related bugs. Both stem from the tooling assuming the package-backed layout without detecting or warning when it isn't there.

**Bug 1 — `OMARCHY_PATH` defaults to `/usr/share/omarchy`, silently breaking `omarchy-migrate --pending` on legacy installs.**

`omarchy-migrate` defaults `OMARCHY_PATH` to `/usr/share/omarchy`. On a legacy git-checkout install that path doesn't exist, so `MIGRATIONS_DIR` doesn't exist either, and `omarchy-migrate --pending` reports **zero pending migrations** — even when dozens actually are — instead of erroring or finding the real checkout. This is a false negative that could easily convince a user their system is fully up to date when it isn't.

**Bug 2 — migration `1785608166` ("Repair the pre-suspend lock monitor's graphical session environment") fails hard on legacy installs, and that failure aborts every migration queued after it.**

That migration calls `systemctl --user reset-failed omarchy-sleep-lock.service`. On a legacy git-checkout install, `omarchy-sleep-lock.service` only exists inside the checkout at `default/systemd/user/omarchy-sleep-lock.service` — it was never symlinked/copied into any real systemd user unit search path, so `systemctl --user status` reports it "could not be found" (not just inactive — genuinely absent). `reset-failed` therefore always fails on this class of install.

The migration's own error message ("The pre-suspend lock repair will be retried by omarchy-migrate.") implies this should be a soft, retryable failure — but `omarchy-update`'s outer script (`set -e` + an `ERR` trap) treats any non-zero migration exit as fatal and aborts the entire run. In our case this stranded **28 migrations** queued behind it that never got a chance to run, with no indication that this was an issue specific to a legacy install vs. a real regression.

## What was expected

Either:
- `omarchy-migrate`/`omarchy-update` should detect a legacy (non-package-backed) install and point the user at `omarchy-upgrade-to-quattro` before attempting migrations that assume the package layout, or
- Migrations that only apply to package-backed installs should detect that and skip cleanly rather than failing, and/or a single migration's soft-failure shouldn't halt every migration queued after it.

## Steps to reproduce

1. Have a pre-quattro Omarchy install still on the legacy git-checkout self-update model (no `omarchy` pacman package).
2. Run `omarchy-update` (or `omarchy-migrate` directly) without first running `omarchy-upgrade-to-quattro` to completion.
3. Observe: `omarchy-migrate --pending` reports nothing pending despite there being many; `omarchy-update` eventually fails on migration `1785608166` with `Unit omarchy-sleep-lock.service not loaded`, aborting the whole migration chain.

We hit this specifically because an earlier `omarchy-upgrade-to-quattro` run was interrupted by an unrelated system freeze partway through, leaving the install in a hybrid state (quattro-branch checkout contents, but none of the package-backed scaffolding). Running `omarchy-upgrade-to-quattro` to completion (idempotent, `pacman -S --needed` throughout) resolved both symptoms as a side effect — filing this because the tooling gave no indication that was the needed fix, and failed in a confusing way instead.

## System

```
Omarchy Package: omarchy 4.0.0-1
Kernel: 7.1.8-arch1-3 x86_64
CPU: AMD Ryzen 9 9950X
GPU: AMD RX 6600 (amdgpu)
Motherboard: ASUSTeK PRIME X670E-PRO WIFI
```

---

Filed by Claude Sonnet 5 via Claude Code.