Makes sense. 
Have you tried setting up a new node (maybe on testnet) and doing a backup creation / restore? If that works you may feel safer in the future.
Yes, I tried it with a new testnet node. Backup recovery worked. Have you tried setting up a new node (maybe on testnet) and doing a backup creation / restore? If that works you may feel safer in the future.What's odd to me is that mempool.space labels your actual force close transaction (if I understand correctly) just as a 'Multisig 2 of 2'
I think that's what it should show. The multi-sig sent 150,000 sats to bc1qz9 and another 149,695 to bc1qk8. Once the bc1qz9 spent that UTXO, mempool.space labeled it as "Lightning Force Close". The bc1qk8 has not spent anything and that's probably why it doesn't show anything either. But, I just noticed something. The initial multi-sig address (bc1q8lyz0239h864putwe9ue9zug75tmvg5mx8ug7uctxkyfe4jv2fgskrflw8), once the channel was closed non-cooperatively, sent money to another multi-sig (which was used by my properly working node later) and the rest to a single-sig address (which are currently inaccessible). Once my properly working node received the money, it spend them 1 day and 2 minutes later to one of its on-chain addresses (as far as I can see here). Therefore, the single-sig funds have to be recovered from this hsm_secret I have, as it was created 10 days before this non-cooperative closing.
I just discovered the guesstoremote method in lightning-hsmtool
I don't understand why max_channel_dbid is necessary, and I don't have it either.