Better if the signed raw transaction to your cold-storage has higher fee rate enough to replace the other transaction.
But since full-rbf still isn't widely used yet, set the original transaction as 'replaceable' in case you need to replace it with the back-to-cold-storage txn.
That will give you a few minutes to "cancel" that transaction.

The wallet file from your Armory datadir will be deleted in the file system as well.
The file name should be similar to "armory_xxxxxxxx_encrypt.wallet".

Here's a related topic with sufficient answers: Delete/Remove Wallet - shred/overwrite, or merely filesystem delete?

I can't reliably tell based from the available info.
But since you've used -proxy, -listen is automatically disabled which made your node unreachable
So try to add "-listen=1" to the command or "listen=1" to your bitcoin.conf file.

Also, if you decided to try the suggestion above, prioritize "addnode" since "connect" will limit you to the nodes that you've set.

You can try FinderOuter tool by Coding-Enthusiast: https://github.com/Coding-Enthusiast/FinderOuter

Follow these steps to use it to find the possible correct characters:

• Open FinderOuter and go to "Missing Base58" tab.
• Select the options at the right-hand side - "*", "Private Key" and "AddrUnComp".
• On the left-hand side, paste your private key in "Base-58 encoded string" and replace the characters that aren't Base58 with *
  for example: 5J1F7GH*dZG3s*CKHCwg8Jvys9xUbFsj*nGec4H1**Ny1V9n*6V
• In the text box under it, paste your address.
• Then Click "Find!" and it will start to fix your WIF private key; it will use most of your machine's CPU process while working.
• Results will be displayed below.
  
  

Of course, it wont display any result if it can't find any valid private key with the characters that you've given.

You need any implementation of Electrum Server to be able to connect your Bitcoin Core to Electrum.
You can try: https://github.com/spesmilo/electrumx - from the main developer of Electrum.

There's the 'law of supply and demand' in economics but it doesn't entirely rely on that.
In your scenario, you can sell the only accessible bitcoin (that you have) with the price that only you can dictate since there'll be no other seller.
So it's up to you if the price will increase or not; but realistically speaking, having near zero liquidity in exchanges can cause it to drop to zero in a matter of minutes to hours.

Plus Bitcoin's price isn't dictated by Bitcoin, I mean not by the developers nor the code; it's the market.
So having all people (the "market") lose their private keys for whatever silly reason, could drop the price to zero.

Yes to non-custodial wallets since transactions have to be included in the blockchain.
For transactions with unconfirmed parent, the parent has to be confirmed first or together with the child transaction(s).
Bitcoin withdrawals from custodial wallets/exchanges also subjected by this but you do not have the control on the fee rate, their charged "withdrawal fee" wont be directly used as transaction fee.

For transfers between non-custodial wallet (e.g.: Coinbase to Coinbase), it's different;
on-platform transactions wont use the blockchain so there'll be no on-chain fee nor waiting time for confirmation.
The downside is, they own your bitcoins.

Most of the time, this isn't necessary specially if you're using "ETA" fee slider which has quite high recommended fee rate.
As long as it's telling you "In the next block" or "Within the next 2 blocks", the fee is alright.
The issue was: there's an unconfirmed parent transaction.

Go to this thread to see the list of bruteforce tools: https://bitcointalk.org/index.php?topic=5422375.0

Those are designed for the puzzle transaction but you can specify the range if you want the whole keyspace. (which isn't comparable to lottery)

There's a downside to that method though: you can't provide an exact time of the draw since blocks aren't always on schedule.
If the application is not strict to schedule, then it's good.

Also, do not use it if the amount at stake is a lot higher than the block reward (like 10x+) since a pool/solo miner can risk it to try produce another block hash with the winning number.

Transaction is now confirmed: https://www.blockchain.com/btc/tx/945e21d24a152b28602de318b2a05e754468c23b46f0db76a5ca148968ddaa4c

In your next transactions:
If you want to avoid creating transactions with unconfirmed parent, you can enable the option: "Tools->Preference->Transactions->Spend only confirmed coins".
But take note that if you do not have other confirmed "Unspent Transaction Output" (UTXO/Coin),
Electrum wont be able to send until there's a suitable amount that's confirmed. ("View->Show Coins" to see the Coins tab)

With the phrase "whoever invented", I think OP is simply thinking that if someone invented something, he must have the knowledge to reverse-engineer it.
...which is not applicable to every invention.

Quite, those are used when deriving the address from the public key, but not the public key itself.
The public key is computed from the private key through "EC point multiplication" along "secp256k1" curve.

Some resources that cover that topic:

• Book - Mastering Bitcoin: github.com/bitcoinbook/bitcoinbook | Chapter4: Keys, Addresses
• Website - Learnmeabitcoin: learnmeabitcoin.com/technical/ecdsa

It's not deemed irreversible just because no one knows the algorithm; the algorithm is available to the public.
It's irreversible because of the method and the amount of computation required to reverse a SHA256 hash.

If you want to literally see how complex it is, try this demo site: https://sha256algorithm.com/
You'll see the relation to pooya's example where it's extremely hard to guess those "x+y" in every step to reverse because the values have already altered by the previous steps.

SHA256 isn't an encryption algorithm, its hash isn't encrypted.

The first address is generated from the uncompressed public key pair of that private key.
The next address is from the compressed public key.

More info here: learnmeabitcoin.com/technical/public-key

Probably because it's designed to bruteforce the "puzzle transaction" (link), and the puzzle's addresses aren't p2sh nor bech32.

Additional fees would just go straight to the miners, extra output for their hidden fee will stick out like a sore thumb as Charles-Tim mentioned.
Plus it wouldn't be practical since small amounts can be troublesome to consolidate.

You're probably thinking of "custodial wallets" which is similar to what OP already pointed out.

The quoted part is called "descriptor", the "db373be9" is just the master fingerprint and not too important.
It's probably because those wallets don't support descriptors and/or Taproot and somehow imported the xpub, but I don't have a Trezor to confirm it.

You can try Sparrow wallet which supports hardware wallets and descriptors. (from Bitcoin.org wallet list)
Things you can try:

• When creating the wallet, select "Legacy" script type but edit the Descriptor to match the xpub of your trezor's Taproot account.
• Or create another wallet, select Taproot but leave the descriptor intact.

Blockchain.com will ask for "email authorization" for new devices/IP even if he didn't set-up 2fa.

But that comes after the wallet ID and password; and before the 2fa code (if 2fa is enabled).
Don't know why he's having trouble with the authorization email while not being able to remember his password.

I've tried it and it worked without an error at my end.

Command used (RegTest):

The only way that error would show is if you set the "locktime" to 4294967294 (which is about 100 years in the future) instead of the sequence.
Compare your command with mine to see the possible issue.

I can't comment on the sequence's inconsistency in createrawtransaction command and GUI. (you may consider opening a new issue for that)

Bitcoin Core doesn't support HD MultiSig wallet so it'll be tricky to backup multiple MultiSig addresses.
No GUI option or menu for MultiSig as well, you'll have to operate using commands.

Yes, Electrum can restore from BIP39 seed phrase and BIP39 passphrase, just enable the options "BIP39 seed" and "Extend this seed with custom words" when importing the seed phrases(s).
Next to that, type the BIP39 passphrase when prompted for the "seed extension".
After that, you'll have to select the correct script type and then edit the derivation path if it's different from the default for P2SH-SegWit MultiSig - m/48'/0'/0'/1'.
But yours is probably more than just m/49 since it's usually the extended master key at BIP38 derivation path's 'script type' level (check your wallet for the correct path).

Wait, you were able to receive BTC through your just-created channel in Electrum?

That will only be an issue if your channel isn't trampoline; you'll see a blue highlight under "can send" row, means that it's frozen.
But as seen in the screenshot, it's connected to a trampoline node (indicated by the kangaroo icon) so there shouldn't be any issue when sending funds.

The only inconsistency I found is the part that I've mentioned (you probably remembered it wrong)