UKI dm-verity uses `PARTNROFF=1/2` — hardcodes BOOT-A / ROOT-A / HASH-A partition adjacency.

**[P2] UKI dm-verity uses `PARTNROFF=1/2` — hardcodes BOOT-A / ROOT-A / HASH-A partition adjacency.**

The `PARTUUID=${boot_partuuid}/PARTNROFF=1` (ROOT-A) and `.../PARTNROFF=2` (HASH-A) references on L530-531 rely on the current on-disk order (BIOS, EFI-A, BOOT-A, ROOT-A, HASH-A). This is fine today, but `sgdisk --sort` (rpm2img:205) reorders by start sector, so any future layout change that inserts a partition between BOOT-A and ROOT-A (or between ROOT-A and HASH-A) — e.g. a LUKS keyslot partition as this feature series grows — silently breaks the UKI verity table. The failure appears at boot as a dm-verity setup error.

**Robust fix:** resolve the real PARTUUIDs of ROOT-A and HASH-A via `get_partition_uuid` and pass them into `generate_verity_root` directly, replacing the offset arithmetic entirely.

_Originally posted by @jmt-lab in https://github.com/bottlerocket-os/twoliter/pull/701#discussion_r3762546124_

Read the UKI generation code around L530-L531 and the rpm2img flow around line 205, then trace get_partition_uuid and generate_verity_root. Done when the generated UKI verity table uses the actual ROOT-A and HASH-A PARTUUIDs rather than PARTNROFF offsets.

Written by the indexing model from the issue text.