### System details

QEMU/KVM VM (OVMF, 16 vCPUs, 8 GB), fresh install from an edge ISO built from omarchy-iso 86c0778 and omarchy b18ab495.

### What's wrong?

On a machine whose ESP is shared with other operating systems, `omarchy-system-factory-reset` drops the other systems' Limine entries and deletes another Linux installation's machine-id directory while it stages the reset. Windows' boot files survive, but Limine no longer lists Windows or the other Linux, so after a reset the Limine menu can only boot Omarchy.

The cause is `reset_limine_config` in `bin/omarchy-system-factory-reset`:

- It copies the shipped template over the ESP's `limine.conf`. That removes every entry that isn't the new Omarchy one, including `/Windows` and other Linux installations, not just the stale Omarchy entry.
- It collects every `machine-id=` in the old `limine.conf` and deletes the matching ESP directory for each one except the new ID. The comment says other installations' directories are safe, but a second Linux install managed by limine-entry-tool is listed in `limine.conf` too, so its directory gets deleted.

**To reproduce:** omarchy-iso's `factory-reset` integration scenario covers this case: `./test/integration <iso> factory-reset`. It adds a `/Windows` entry and a second Linux entry to the ESP, with a foreign machine-id, boot directory, and UKI, and then runs the reset. The staging checks:

```
not ok - windows entry survives staging
ok - windows boot payload survives staging
not ok - foreign linux entry survives staging
not ok - foreign boot directory survives staging
not ok - foreign UKI survives staging
ok - old omarchy entry is removed by staging
ok - old omarchy boot directory is removed by staging
ok - a fresh omarchy entry exists after staging
```

I read the staged ESP directly:

- `EFI/Microsoft/Boot/bootmgfw.efi` and `EFI/Linux/foreign_linux-omarchy.efi` are still there.
- `limine.conf` contains only the new Omarchy entry and the EFI fallback.
- The foreign `/<machine-id>/` directory is gone.

**The `foreign UKI` check is itself stale.** It looks for `EFI/Linux/foreign_linux.efi`, but since the ISO switched to `linux-omarchy`, the fixture creates `foreign_linux-omarchy.efi`. That UKI survives, so this check fails on the wrong path. The other three failures are real.

**A possible fix:** keep the existing `limine.conf` and remove only the OS entries and directory that belong to the machine-id being replaced, instead of starting over from the template.

**Also noticed, not investigated:** after staging, the new entry's cmdline has an empty `resume=` (it was `resume=/dev/vda2` before the reset). The UKI rebuild in the chroot also logged `==> ERROR: failed to detect root filesystem` from mkinitcpio's `autodetect` hook. I haven't checked whether resuming from hibernation still works after a reset.