If TOTP unsealing fails, HOTP isn't updated

Nobody has claimed this yet.

If TOTP unsealing fails, the HOTP status isn't updated. In some cases this can mean it displays "success" incorrectly if it had previously traced success. (This means they both had to unseal at some point, then a change was made that causes TOTP to fail unsealing, such as entering the recovery console and returning to gui-init.)

The HOTP unseal currently only occurs if TOTP unseal succeeds: `update_totp && update_hotp`. This avoids counting two failures toward dictionary attack lockout if unseal fails, since both TOTP and HOTP each separately try to unseal the same secret.

This was briefly changed to be independent: `update_totp; update_hotp`. This ensures HOTP is always up to date, but counts two failures toward DA lockout if unseal fails. (TPM2 is currently configuring 10 auth failures to DA lockout, TPM1 limits vary by TPM vendor.)

We probably need a flow like:
```
if `unseal_secret`; then
update_totp "$secret"
update_hotp "$secret"
else
TOTP="Unable to unseal"
HOTP="Unable to unseal"
fi
```

This would only unseal once when preparing the menu, but still always update both TOTP and HOTP.

Locate the menu flow containing update_totp, update_hotp, and unseal_secret. Trace how the current update_totp && update_hotp path handles unseal failure, then verify that one unseal attempt updates both statuses on success and shows “Unable to unseal” for both on failure. Done means HOTP cannot retain a prior success when TOTP unsealing fails, without counting a second failed unseal.

Written by the indexing model from the issue text.