This is basically the setup I ended up building, except I went all-software for all three keys instead of keeping two HWWs. For what it's worth, your hybrid is arguably better diversified than mine: two independent secure elements plus one airgapped software signer covers more failure modes than three software keys do.
A few things from actually doing it end to end (deposit, cold sign, broadcast, confirmed on mainnet):
I used Sparrow instead of Electrum on the Tails stick. Same idea, but the multisig UX is cleaner, the PSBT-over-USB flow is exactly the gapless signing you're describing, and it let me cross-check every receive address against Bitcoin Core's deriveaddresses and a third generator before funding. That cross-check is five minutes and it's the only step that catches a silently wrong descriptor.
On the dice entropy: watch out for one thing no guide I found gets right. The seed tool applies bias correction, so "99 rolls = 256 bits" isn't true in practice. In my run, 100 rolls credited 163 bits, not 256. The rule has to be "roll until the counter shows 256 real bits," which took me around 140. Stop at 99 and you still get 24 valid words and a working wallet, you just quietly have less entropy than you think.
The design decision I'd think hardest about: do you want that software key at rest or not? Your proposal (Electrum in LUKS persistent storage) keeps the seed on the stick, encrypted. I went the other way: nothing persists, the seed lives only on paper and steel, and I retype it into a freshly rebuilt wallet each time I sign. More annoying per signature, but there's no key at rest whose safety rides on the LUKS passphrase plus that machine never being compromised. Both are defensible, it depends on your threat model. Worth deciding on purpose rather than by default.
I documented the whole procedure, including the three mistakes I made and a fingerprint I got wrong in an earlier version: https://github.com/NoaSEED/bitcoin-vault-2of3 , the entropy and descriptor-backup sections are the ones I'd most want eyes on. I also wrote up the vendor-risk reasoning behind the whole thing here on SN, which is basically your starting point after Coldcard: #1545677
This is basically the setup I ended up building, except I went all-software for all three keys instead of keeping two HWWs. For what it's worth, your hybrid is arguably better diversified than mine: two independent secure elements plus one airgapped software signer covers more failure modes than three software keys do.
A few things from actually doing it end to end (deposit, cold sign, broadcast, confirmed on mainnet):
I used Sparrow instead of Electrum on the Tails stick. Same idea, but the multisig UX is cleaner, the PSBT-over-USB flow is exactly the gapless signing you're describing, and it let me cross-check every receive address against Bitcoin Core's deriveaddresses and a third generator before funding. That cross-check is five minutes and it's the only step that catches a silently wrong descriptor.
On the dice entropy: watch out for one thing no guide I found gets right. The seed tool applies bias correction, so "99 rolls = 256 bits" isn't true in practice. In my run, 100 rolls credited 163 bits, not 256. The rule has to be "roll until the counter shows 256 real bits," which took me around 140. Stop at 99 and you still get 24 valid words and a working wallet, you just quietly have less entropy than you think.
The design decision I'd think hardest about: do you want that software key at rest or not? Your proposal (Electrum in LUKS persistent storage) keeps the seed on the stick, encrypted. I went the other way: nothing persists, the seed lives only on paper and steel, and I retype it into a freshly rebuilt wallet each time I sign. More annoying per signature, but there's no key at rest whose safety rides on the LUKS passphrase plus that machine never being compromised. Both are defensible, it depends on your threat model. Worth deciding on purpose rather than by default.
I documented the whole procedure, including the three mistakes I made and a fingerprint I got wrong in an earlier version: https://github.com/NoaSEED/bitcoin-vault-2of3 , the entropy and descriptor-backup sections are the ones I'd most want eyes on. I also wrote up the vendor-risk reasoning behind the whole thing here on SN, which is basically your starting point after Coldcard: #1545677