### System details

Upgrade from an existing encrypted Omarchy installation to Quattro; LUKS root with Btrfs, EFI system partition at `/boot`, Linux `7.1.8-arch1-3`, Limine `12.5.2`.

### What's wrong?

The Quattro upgrade can carry a systemd/sd-encrypt kernel parameter into a UKI built with Omarchy's classic mkinitcpio `encrypt` hook, leaving encrypted-root systems unbootable.

After the upgrade, both Limine and the old systemd-boot entry failed with:

```text
ERROR: Failed to mount '/dev/mapper/root' on real root
You are now being dropped into an emergency shell.
```

In the emergency shell, `/dev/mapper` contained only `control`; the physical root partition was present and correctly identified as `crypto_LUKS`. Manually running `cryptsetup luksOpen /dev/sda3 root` created `/dev/mapper/root`, after which `blkid` identified the expected Btrfs filesystem and it mounted successfully. The LUKS metadata, passphrase, and filesystem were therefore healthy; automatic activation in the initramfs was missing.

`omarchy-upgrade-to-quattro` wrote `/etc/default/limine` with the correct redacted LUKS UUID but the wrong parameter for the resulting initramfs:

```text
rd.luks.name=<LUKS_UUID>=root root=/dev/mapper/root rw
```

The generated UKI contained that command line. However, Quattro ships `/etc/mkinitcpio.conf.d/omarchy_hooks.conf` with:

```text
HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs)
```

That is the classic `udev` + `encrypt` path. Its volume selector is `cryptdevice=`; `rd.luks.name=` belongs to the `systemd` + `sd-encrypt` path and is ignored by the effective initramfs.

Replacing the generated selector with:

```text
cryptdevice=UUID=<LUKS_UUID>:root root=/dev/mapper/root rw
```

and running `limine-mkinitcpio` restored normal boot on the affected machine.

The source of the mismatch is the root-command-line preservation loop in `bin/omarchy-upgrade-to-quattro`: it copies `rd.luks.name` from `/proc/cmdline` verbatim even though the package transaction installs the classic `encrypt` hook before rebuilding the UKIs.

This is related to #6728 because the failure occurs before encrypted root is mounted, but #6728 was ultimately attributed to an Intel microcode regression. PR #6758 independently notes that Omarchy's `encrypt` hook ignores `rd.luks.*`, but it only hardens validation and deliberately continues copying those parameters; it does not convert the incompatible selector.

Expected behavior: when the Quattro upgrade carries forward `rd.luks.name=<uuid>=<mapper>` from a pre-Quattro sd-encrypt boot, it should write the equivalent `cryptdevice=UUID=<uuid>:<mapper>` selector required by Omarchy's effective classic `encrypt` hook before regenerating Limine entries and UKIs.