1.12.0 — 4096-byte encryption sectors; stale EFI entries removed where U-Boot actually keeps them

AsahiLocker 1.12.0 — 4096-byte encryption sectors; stale EFI entries removed where U-Boot actually keeps them

Two things learned by restore-testing an M2 Max with linux-backup-system,
applied here.

4096-byte LUKS sectors (luks-deploy.sh)

Apple NVMe is a 4096-byte-sector disk and btrfs writes 4096-byte blocks, but
cryptsetup's default encryption sector is 512 — so every volume this script
made, the author's own included (sector: 512 [bytes] on a 4096/4096 disk),
did eight XTS operations with eight IVs per filesystem block. reencrypt --encrypt now gets --sector-size 4096 whenever the btrfs sectorsize allows
it (always, on Asahi), the plan and pre-flight summary say so, and the
verification gate (V10) confirms the open container's sector size against the
plan. Verified in place on cryptsetup 2.8.8 for a 4096-byte-sector device and
a 512-byte one; tests/loopback-core-test.sh now covers both (27 checks).
LUKS_SECTOR_SIZE=512|1024|2048|4096 pins it; it can never exceed the
filesystem's sectorsize. Existing volumes are unchanged — as secure as before,
just slower — and the README says how to change one (a full in-place
re-encryption, not a luks-tune job).

clean-stale-efi-entries finally cleans them

U-Boot keeps its non-volatile EFI variables in ubootefi.var on the ESP
(lib/efi_loader/efi_var_file.c) and writes that file only from its own
boot-time code. efibootmgr -B from Linux edits U-Boot's in-memory runtime
copy and nothing else (efi_set_variable_runtime; Kconfig
EFI_RT_VOLATILE_STORE: "the OS will be responsible for syncing the RAM
contents to the file, otherwise any changes made during runtime won't persist
reboots"). So the guard "deleted" the same stale entries at every boot and
they came back at every boot.

New boot-guards/bin/uboot-efivar.py parses the file with U-Boot's own
layout (include/efi_variable.h), decodes each Boot#### load option's
device path, drops the entries whose GPT partition is on no attached disk,
takes them out of BootOrder, recomputes the CRC32 and replaces the file
atomically, keeping the previous one beside it. The guard runs it on U-Boot
hosts (then efibootmgr -B on the runtime copy so the running system
agrees); real UEFI firmware keeps the efibootmgr-only path. Installed by
boot-guards/install.sh, covered by tests/uboot-efivar-test.sh (14 checks,
in CI), verified against this machine's real file: Boot0006, a Fedora USB
installer's partition long unplugged, is the entry it removes.

Smaller

• The ESP vendor directory is found, not assumed: the directory under
  EFI/ that holds this arch's GRUB or shim (EFI/fedora on Fedora Asahi
  Remix, whose os-release says ID=fedora-asahi-remix) — in both boot guards
  and their installer, ESP_GRUB_CFG still overriding.
• save-luks-recovery-bundle.sh saves ubootefi.var (the boot entries
  themselves) beside efibootmgr.txt, and its recovery notes say which of
  the two restores an entry under U-Boot.
• docs/UBOOT-BOOTFLOW.md: a section on where the EFI boot entries live,
  with the U-Boot source it comes from.