v3.7.0 — restore finds the ESP at /efi; fstab/crypttab ids rewritten by field; verified on EndeavourOS

Verified on EndeavourOS: a 2014 ASUS X750JN, ext4 root on LUKS2, plain vfat /boot (XBOOTLDR) + ESP at /efi, systemd-boot, dracut. deploy.sh set up the USB NVMe backup drive, then real borg, Back In Time, Timeshift and LUKS header backups ran and backup-verify.sh reported 0 FAIL. The Arch / Manjaro / EndeavourOS and plain /boot rows are ✅.

Restore fixes — each would have left a restored machine unbootable or misreported:

• Both restore scripts looked for the ESP only at /boot/efi. With the ESP at /efi, its fstab UUID was never rewritten and the restored system hung at boot.
• fstab/crypttab IDs were matched on the substring UUID=, which also matched inside PARTUUID=. They are now parsed by field and rewritten in the form each entry already uses (UUID=, PARTUUID=, LABEL=, PARTLABEL=).
• The post-restore check stopped at its first count (((X++)) under set -e), and it knew only /boot/vmlinuz-*. It now also counts kernel-install entries and UKIs.
• An ESP mounted directly at /boot is recognised. The new disk's partition types (ESP = EFI System, a separate vfat /boot = XBOOTLDR) are checked before anything is rewritten, and each warning prints the sgdisk fix.

deploy.sh fixes found on Arch: an unbound variable made the capacity check count only /; deploying with no drive connected aborted on every non-btrfs host; a non-blank SD card listed last aborted the deploy; a disk with only a partition table was described as having a filesystem.