Can someone explain - I am told best practice is to update Qubes and then when dom0 is updated (and HOTP/TOTP not matching anymore), to sign the updates? Is this done in Heads? I could not find instructions.
Updating dom0 should not have any impact on TOTP/HOTP, which are firmware related verification mechanisms.
TOTP is time based, and relies on QR code you scanned with your phone to produce that 6 digits number that changes every 30 seconds on both phone and laptop, if both time and date are in sync (and laptop time and date is in GMT/UTC). It is a manual and offline verification. And it requires the system to have recently have been time synchronized over the network per normal daily usage, or manual time synchronization.
HOTP on the other hand is verification protocol and simply requires to plug in you GPG dongle so that a handshake verifies and confirms the state.
If TOTP is right but HOTP is wrong, there is something wrong with the GPG dongle. Those are used to verify the firmware integrity (Heads) which then verifies the OS binaries against what the user signed previously.
When you update dom0, high are chances that /boot will have a new Xen/kernel/initird deployed, oldest kernel removed and grub.cfg updated to point to new xen+kernel+initrd combination.
When attempting to boot your default configuration through Heads, Heads will verify detached signed /boot content and report a mismatch for changed files.
This is also where Heads will ask you to update checksums file and its detached signature. That is, Heads verifies that the /boot digest (checksum file) detached signed against your public key fused in firware.
When you sign /boot content, you use your gpg dongle and type your User PIN to authenticate yourself to the dongle for it to sign the digest. On each boot after, Heads verify the detached signature file against your public key, and then verifies that the digest matches the content of the files under /boot.
Documentation is here: Step 4 - Installing Qubes and other OSes - Heads - Wiki (see subpoints)
It is possible, to some limited extend, to verify xen/kernel/initrd: Verifying installation