TPM reset is complex

Nobody has claimed this yet.

The UX flow to reset the TPM and get back to a fully working state is pretty complex and requires knowledge of how Heads works that isn't obvious.

Currently, we rely on the fact that firmware upgrades in the absence of a TPM disk unlock key can get back to "working" just by resealing TOTP/HOTP, but this is somewhat fragile (relies on user to know to pick reseal over reset on the boot prompt, and there are a lot of ways the signatures could change that would now require TPM reset).

I see three issues making the TPM reset flow more complex than just resealing:

* You have to know to go to sign /boot afterward. If you don't and just try to default boot, it chokes and drops you to recovery, inexperienced user has no idea how to get back into the system
* You have to enter a lot more passwords, just more cumbersome
* You don't know if your /boot signatures were still valid, if you expected them to be but they were not, they get re-signed anyway. Maybe this isn't as useful as I think?

Some of this could be improved by extending the TPM reset UX.

Start by tracing the existing TPM reset, reseal, and sign /boot flows described in the issue. Document the passwords, boot prompts, signature checks, and recovery transitions involved, then define the desired reset behavior and how a user can reach a fully working state. Confirm the design against firmware upgrade and default-boot scenarios.

Written by the indexing model from the issue text.