Provide guidance if restoring across reinstalls (new UUID for LUKS)

[EricCousineau-TRI]

Is your feature request related to a problem? Please describe.
Relates #301

During experimentation, I found that I had borked my system, and wanted to "start from scratch" by reinstalling, and then attempting to do a snapshot restore.
Of course, I'm realizing that this is perhpas not a supported workflow, as the OS install probably depends on the root partition UUID, at least for LUKS encryption.

Describe the solution you'd like
Options, in ordered by my perceived effort, least to most:

(a) Add documentation that says "beware if you do this, it'll break"

(b) Add documentation with guidance on "here's how you can maybe fix it it" (I have no idea if these actually work)
(b.1) use sudo cryptsetup luksUUID <dev> --uuid <uuid> for encrypted devices, and cross your fingers
(b.2) edit things like /etc/crypttab, /boot/grub/grub.cfg, and replace <old uuid> with <new uuid>, and cross your fingers

(c) Detect that UUID list has changed from backup to restore, notify user that it could be broken, and attempt best effort "replace" (i.e., restore, replace UUIDs, and cross your fingers).

Describe alternatives you've considered
N/A

Additional context
Relates #301

[beerriot]

The PR I just opened fixes the specific instance of this I encountered, where Timeshift did not update the LUKS UUID because it was an extra layer away from the partition being mounted (via LVM). So, it's possible that the guidance is no longer needed. Except for maybe a note that the restore cannot target the live-running system (i.e. it needs to be run from something like a live USB image if you're restoring to the system's "main" drive).

I also wrote up a blog post outlining specific steps to change UUIDs on fresh partitions, to match the snapshot, in case I ever needed to recall that process. In case other people running into this problem end up at this github issue, that post is here: https://blog.beerriot.com/2025/03/15/year-of-linux-pt4/