### System details

```
$ omarchy version
4.0.0-1
$ limine --version
Limine 12.5.2
$ pacman -Q limine-snapper-sync
limine-snapper-sync 1.31.0-1
```

Single NVMe drive, UEFI, Secure Boot disabled. Existing Windows 11 install with its own ESP, installing Omarchy "alongside existing data" into free space on the same disk.

### What's wrong

Two separate, independently-confirmed bugs, compounding into "Windows disappears from the boot menu after a dual-boot install":

**1. The installer ignores the existing Windows ESP and creates its own new one.**

Partition layout before install:

```
nvme0n1p1 — Windows ESP, VFAT, ~100 MB (EFI/Microsoft, EFI/BOOT) — the ESP firmware actually boots from
nvme0n1p2 — Microsoft Reserved
nvme0n1p3 — Windows
nvme0n1p4 — Windows Recovery
```

After choosing "install alongside existing data" into the free space, the installer created a **new** 2 GB ESP (`nvme0n1p5`, label `omarchy-efi`) and installed Limine there, rather than adding an entry to the existing `p1` ESP. The new ESP's Limine install registered a firmware boot entry, but not one the firmware surfaced in its top-level boot list — it only showed up buried in a vendor-specific submenu ("UEFI NVMe Drive BBS Priorities"). Net effect: the machine booted straight to Windows with no visible way in.

This reproduced identically on a second from-scratch install (first attempt's partitions were wiped and redone) — same free-space option, same result: a second orphaned 2 GB ESP. Not a one-off.

Recovering from this required manually chrooting in, reinstalling Limine, and repointing `/etc/fstab`'s `/boot` mount from the stray `p5` ESP to the real `p1` Windows ESP — plus later deleting the now-duplicate, unmanaged Limine boot entry on `p5` via `efibootmgr` once it was clear the firmware was booting the wrong (stale) one.

**2. `omarchy-refresh-limine` unconditionally destroys any Windows entry and never restores it.**

`/usr/share/omarchy/bin/omarchy-refresh-limine`:

```bash
sudo mv /boot/limine.conf /boot/limine.conf.bak
sudo cp "$OMARCHY_PATH/default/limine/limine.conf" /boot/limine.conf
sudo limine-update
sudo limine-snapper-sync
```

The template it copies in (`$OMARCHY_PATH/default/limine/limine.conf`) contains **zero OS/boot entries** — only theming. `limine-update` only reinstalls the Limine binary and regenerates Linux kernel/UKI entries (`limine-install --no-efi-register` + `limine-mkinitcpio`); `limine-snapper-sync` only manages Btrfs-snapshot entries. Neither calls `limine-scan` / `limine-entry-tool --scan`, which is the only mechanism that detects and chainloads `bootmgfw.efi`.

So any Windows entry present in `limine.conf` — whether added by the installer's own scan pass or by a user running `limine-scan` manually — is silently and permanently discarded the next time `omarchy-refresh-limine` runs, and nothing downstream re-adds it. Confirmed by diffing the live `/boot/limine.conf` (Windows entry present) against `/boot/limine.conf.bak` (only the bare `EFI fallback` entry, no Windows, no Omarchy) — the `.bak` is exactly what the wipe-then-partial-rebuild leaves behind.

This is the same class of bug fixed for the factory-reset path in #6847 (wholesale `limine.conf` overwrite dropping foreign entries) — but that PR only touches `bin/omarchy-system-factory-reset`, not `omarchy-refresh-limine`, so this code path is still affected.

### What was expected

- Installing alongside an existing Windows install should reuse the existing ESP (or at minimum warn/prompt when a usable one is already present) rather than silently creating a second one that firmware may not surface.
- `omarchy-refresh-limine` should not destroy manually- or installer-scanned foreign OS entries. Either preserve existing non-Omarchy blocks when rewriting the file, or re-run `limine-scan` as part of the refresh so they're rebuilt rather than dropped.

### Steps to reproduce

1. Have an existing Windows 11 install with its own ESP on a single-disk UEFI machine.
2. Install Omarchy via the "install alongside existing data" free-space option.
3. Observe a new, separate ESP is created rather than the existing Windows one being used; Windows is missing from the boot menu.
4. (Separately) On a system with a working Windows entry in `limine.conf`, run `sudo omarchy-refresh-limine`, then check `/boot/limine.conf` — the Windows entry is gone.

### Possibly related

- #7515 — free-space install doesn't work alongside non-OS partitions
- #4579 — dual-boot install, Windows entry missing from Limine/UEFI (different disk layout, same symptom family)
- #1401 — installing from `omarchy-online.iso` wipes the Windows 11 boot entry (closed, no visible fix — may be a regression if this still reproduces)
- #6847 — fixes the same "unconditional `limine.conf` overwrite drops foreign entries" bug class, but only for factory-reset, not `omarchy-refresh-limine`

---

Filed by Claude (Sonnet 5) via Claude Code.