AsahiLocker 1.12.1 — the full review, and the first end-to-end run on a test disk

Every script read end to end against what the linux-backup-system restore
test bed and the U-Boot source established this week, then luks-deploy.sh
run for real: a plain, unencrypted copy of a Fedora Asahi Remix system built
on a 60 GiB loop image (booted in QEMU first, to prove the rig), encrypted in
place by the script — fast profile, recovery key, 4096-byte sectors, the
12-point gate ALL CHECKS PASSED — then booted in QEMU again with the
passphrase, to a login prompt. The recovery key opens it; the recovery bundle
ran against the mounted target in live-USB mode. No physical disk was
touched.

Found by that run, fixed

• 4096-byte sectors were unreachable on most 512-byte-sector disks. GPT
  reserves 33 sectors at the end of a disk, so the last partition — an
  installer's "rest of the disk" root — is always 33 sectors short of a
  4096-byte multiple, and cryptsetup refuses --sector-size 4096 on it
  ("Device size is not aligned to requested sector size"). 1.12.0 fell back
  to 512 with one warning. Now it is a choice: type ALIGN (or
  LUKS_ALIGN_PARTITION=yes) to move the partition's end down by the
  remainder — the table is backed up first to the state directory with the
  restore command logged, one sgdisk call keeps the number, start, type,
  name, unique GUID and attributes, the kernel's view is verified, and the
  filesystem (already 32 MiB smaller) loses nothing — or press Enter for
  512-byte sectors. Never a default. Exercised for real on the 60 GiB image
  (3,584 bytes moved) and in the loopback test against a GPT image whose
  partition ends on the reserved tail. On Apple's 4096-byte-sector NVMe the
  question never comes up.
• The recovery bundle, in live-USB mode, copied every LUKS header it could
  see — another machine's backup drive plugged into the rescue system
  included. It now keeps to the target's own volumes: its root and what its
  crypttab names; others are listed and skipped.
• esp-grub-stub-rebaseline still assumed EFI/fedora; it finds the
  vendor directory like the two guards do.
• luks-tune.sh shows the encryption sector size beside the keyslots, so
  a volume made before 1.12.0 (512-byte sectors on a 4096-byte disk) is
  recognisable there.

Confirmed by the review

luks-deploy.sh's partition picker and pinning, the mapper cross-wiring
guard, the fstab cross-check, the resume and config-only paths, the
luksAddKey --hash sha512 recovery slot, GRUB_CMDLINE_LINUX_DEFAULT
handling, the ESP-stub protection, the chroot rebuild with its dm-crypt and
keyboard-driver checks, and the verification gate all hold. Loopback test:
36 checks.