install to-disk with LUKS + TPM broken

Does `bootc install to-disk --block-setup tpm2-luks /dev/diskX` actually work? I tried this in a qemu virtual machine with emulated TPM (via swtpm) and while it installed successfully, upon rebooting the VM into the freshly installed OS the `systemd-cryptsetup` units failed to decrypt the LUKS volume. Has this actually been tested or otherwise known to work? ~~I will try on real hardware but this has me concerned this feature is not really in a functional state.~~

I tested with vanilla Fedora 39 Server to try and rule out this being related to the use of a virtual machine with emulated TPM. After installing tpm2-tools, adding the tpm2-tss dracut modules, and running systemd-cryptenroll for the LUKS volume I had an installation that repeatedly would unlock automatically via the TPM at boot (no password and no failures). Also tried with Fedora 39 Silverblue (added modules to initrd and enabled custom initramfs generation with rpm-ostree) -- same results. In both cases the LUKS volume was enrolled after the installed OS was provisioned and booted for the first time although I really doubt that has any effect on anything. I do not believe the test setup (IE: emulated TPM) is the problem here though.

Eventually dracut times out and drops into a rescue shell in the initrd. The cryptsetup unit faied with a `Current policy digest does not match stored policy digest, cancelling TPM2 authentication attempt.` error. Further, an error of `No passphrase or recovery key registered` is also printed. I don't think this is a PCR issue.

Some observations:
- The latter of these issues (lack of failover way to unlock) is most certainly a bug in this install path. If the means for unlocking the LUKS volume will be the TPM, a recovery key **must** be set to allow the system to boot in the event PCRs change. Alternatively, allow the user to provide a normal password. One or both of these failover methods needs to be supported at install time (not after).
- It is not clear from the documentation or CLI interface what PCRs the volume gets bound to in the TPM. The defaults should be documented and also user configurable. Right now based on reading the source, it looks like the LUKS volume binds to ~~no PCR so it will always unlock as long as the TPM is present~~ PCR 7, the [systemd-cryptenroll default](https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptenroll.html#--tpm2-pcrs=PCR).

Reproduce `bootc install to-disk --block-setup tpm2-luks /dev/diskX` in QEMU with swtpm, then inspect the `systemd-cryptsetup` and dracut failure output, including the PCR policy and missing recovery key. Done means the installed system can unlock successfully at reboot and has a supported recovery path; document or expose the PCR behavior if that is part of the fix.

Vom Indexierungsmodell aus dem Issue-Text verfasst.