## What happened

`omarchy hibernation remove` reports `Hibernation removed`, but it only removes the
mkinitcpio `resume` hook. It never removes `/etc/limine-entry-tool.d/resume.conf`, which
`omarchy-hibernation-setup` created. Because the removal script ends with
`sudo limine-mkinitcpio`, the drop-in is still on disk during that rebuild, so the freshly
generated UKI **and every entry in `/boot/limine.conf`** come out carrying:

```
resume=/dev/mapper/root resume_offset=1909033
```

At that point the swapfile has already been deleted and the `/swap` Btrfs subvolume
destroyed, so the kernel command line points at an offset inside blocks Btrfs is now free
to hand to any other file.

## Expected

`omarchy hibernation remove` should delete the drop-in it created before rebuilding, so the
resulting cmdline has no `resume=` / `resume_offset=`.

## Steps to reproduce

1. `omarchy hibernation setup` on a Btrfs + LUKS install using Limine/UKI.
2. `omarchy hibernation remove`, confirm the prompt.
3. Inspect the result:

```console
$ ls /etc/limine-entry-tool.d/
omarchy-defaults.conf  omarchy-uki.conf  resume.conf        # <-- still there

$ grep -c "resume=" /boot/limine.conf
5

$ sudo grep -aoE "resume(_offset)?=[^ ]+" /boot/EFI/Linux/omarchy_linux.efi | sort -u
resume=/dev/mapper/root
resume_offset=1909033

$ swapon --show                 # the swapfile it points at is gone
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition  15G   0B  100

$ ls -d /swap
ls: cannot access '/swap': No such file or directory
```

## Where the asymmetry is

`omarchy-hibernation-setup` creates the drop-in:

```bash
RESUME_DROP_IN="/etc/limine-entry-tool.d/resume.conf"                                 # line 31
...
echo "KERNEL_CMDLINE[default]+=\" resume=$RESUME_DEVICE resume_offset=$RESUME_OFFSET\"" \
  | sudo tee "$RESUME_DROP_IN" >/dev/null                                             # line 103
```

`omarchy-hibernation-remove` never references `RESUME_DROP_IN` at all — its only `rm` calls are:

```bash
sudo rm "$SWAP_FILE"          # line 30
sudo rm "$MKINITCPIO_CONF"    # line 49
sudo limine-mkinitcpio        # line 52
```

The same gap applies to `/etc/limine-entry-tool.d/rtc-alarm.conf`, which
`omarchy-hibernation-setup` creates on s2idle systems (line 111-114) and `remove` also leaves
behind. (Not present on my machine, so I only verified `resume.conf` end to end.)

## Second-order: the snapshot entries cache the stale cmdline

Deleting the drop-in and re-running `limine-mkinitcpio` cleans the default entry and the UKI,
but the Snapper snapshot entries keep the old cmdline, because it is cached in
`/boot/<machine-id>/limine_history/snapshots.json`. Restarting `limine-snapper-sync.service`
regenerates the entries from that cache, so it does not help. The stale `resume=` has to be
stripped from `snapshots.json` as well.

## Impact

Low probability, but it is exactly the failure class hibernation removal is meant to end: a
kernel command line telling the kernel to resume from freed, reallocated blocks. It also makes
a later `omarchy hibernation setup` start from a half-configured state (see #7619).

## Suggested fix

In `omarchy-hibernation-remove`, before `sudo limine-mkinitcpio`:

```bash
RESUME_DROP_IN="/etc/limine-entry-tool.d/resume.conf"
RTC_DROP_IN="/etc/limine-entry-tool.d/rtc-alarm.conf"
[[ -f $RESUME_DROP_IN ]] && { echo "Removing resume kernel parameters"; sudo rm "$RESUME_DROP_IN"; }
[[ -f $RTC_DROP_IN ]] && sudo rm "$RTC_DROP_IN"
```

and additionally strip `resume=`/`resume_offset=` from
`/boot/<machine-id>/limine_history/snapshots.json` so the snapshot entries stop resurrecting it.

## System

| | |
|---|---|
| Omarchy | 4.0.2-1 |
| Kernel | 7.1.9-arch1-2 |
| CPU | AMD Ryzen 5 5600G |
| GPU | NVIDIA GeForce GTX 1660 SUPER (nvidia-open-dkms 610.57.04) |
| RAM | 15 GiB |
| Root | Btrfs on LUKS, Limine + UKI |
| limine | 12.6.0-1, limine-mkinitcpio-hook 1.37.1-1, limine-snapper-sync 1.31.0-1 |

PARTUUIDs redacted from the pasted cmdline above; full `omarchy debug` output available on request.