Depending at which stage of install the crash happened and what actions were taken, its very difficult to remotely diagnose this. In heads, HOTP is used to attest that the contents of the firmware/BIOS CBFS (including GPG cert) have not changed. The fact that HOTP. has got out of sync is concerning, as why would that happen when simply changing the contents of the OS? The only time Heads is concerned with the OS is that it validates the contents of /boot using GPG signing. The GPG key is in the BIOS firmware CBFS, and the HOTP attests the Heads firmware (and thus GPG key for /boot signing) has not changed
What I can factually tell from your posts (both here and at nitrokey) is: During an upgrade, your system behaved unexpectedly for an unknown reason. You did a hard reset. Your HOTP code then showed as not matching and your system wont boot any more. To try to get running again, you clicked on the buttons in Heads to re-sign /boot and also made a new HOTP by re-certifying the firmware as known good.
If i was in that situation I would be considering a full machine reset, refreshing heads using a SOIC and reinstalling the OS. I probably wouldn’t be re-certifying the firmware with a new HOTP code without understanding first why the existing HOTP became invalid. Thats kinda a big alarm bell in Heads.