It wont work.
By forcing to encode the PubKeyHash with "base58check (-z)" encoding, it will produce a non-standard address.
It will produce an address with the correct code, yes; but the standard clients that use base58 simply wont be able to decode your addresses correctly.

"wallet_1" is the default wallet name of the second wallet that you've created, perhaps that seed phrase is only for the first wallet "default_wallet".
The question is, where did "wallet_1" came from?

An address can't be deleted even from an imported wallet.
And the only reason that a wallet is labeled "watching-only" is if it's created by importing address(es) or 'master public key'.

If your main account is a newbie, you can try to ask a moderator to "nuke" it.
That will wipe all of that account's posts and ban it.

But it's not possible if it's a Jr member or above, only the admin can do that.

Here's how to find moderators or the Admin: /index.php?topic=703657.0

If it's not the transaction fee, it's the block time.
The 10 minutes block time is just an average, it can go up to hours or down to seconds depending on the miners' luck.
Moreover, it can also be affected by miners shutting down/powering up their farms causing a drastic changes in difficulty in the next retarget.

"Double-spend" is loose term, I think you mean reverting an already confirmed transaction and replacing it with another, based form the thread's topic.
Honestly, IDK if there are other ways to do that aside from the mentioned attack, others might know.

Uhm, that's per unit.
You need about 1million units to reasonably do the attack.

51% attack was already discussed multiple times and received great replies in the board that I've mentioned.
I'd suggest you to follow my instructions above to be able to see those topics.

Do you mean 51% attack?
Basically, you need to have 51% of the network's hashrate or more to have a reasonable chance of success.

Currently, the network's total hashrate is (getmininginfo):
Which is roughly 204.257 Ehash/s, half of that is 102.129 Ehash/s
Which is equal to 928,440 units of Antminer S19 Pro (110TH/s advertised hashrate | $4~5k average price)

With that, I think you can get the picture of the cost; not to mention, the availability of the required mining equipment.

For more info, I'd suggest you to go to this board: Development & Technical Discussion
The use the search box at the upper-right side of the page to search for "51% attack".

Yes, it's working.
The "help" result is displayed since you don't added any command-line options.

Those command-line options  should be supplied together or pywallet.py --recover wont proceed (it will tell you what parameter is missing).
And yes, the "recov_size" is the size that you want pywallet to check, it can be lower than the disk's size but checking the disk's full size is recommended.
For the "recov_device" letter, it should be the same as the (clone) Disk's drive letter as seen in your File Explorer or Disk Management.
"recov_outputdir" is where the recovered_wallet.dat will be saved.

After successfully entering a proper command, it will ask you to provide password for the wallet.dat that it will create where the recovered keys will be saved.
Then a bunch of possible passwords of the deleted keys or wallets (one line [password->enter] per password, leave the last one blank [just press enter] to begin the search).
note: characters wont be displayed while you're typing the passwords.

You're probably right (given your post history).

After loading the wallet, instead of getting: Wallet File Version = n
and Keys: n plaintext, n encrypted, n w/ metadata, n total. Unknown wallet records: n

Those are replaced by:

Try to launch Bitcoin Core with -debug=walletdb command-line option to output wallet database-related info or -debug=1 to enable all categories.
Then re-check the logs if you can find an error related to the crash.

You can use -recan in the console as well if you do not know how to launch it with addition command line option.
Just open the console "Window->Console" and type: rescanblockchain to scan from the genesis block up to the tip.

BTW, the latest version of Bitcoin Core is set to prune the blockchain by default. If you haven't unchecked it in the initial setup, your node's blockchain is pruned.
You can see it in the settings: "Settings->Options...->Prune block storage to"

Blockchair (the one LoyceV suggested) is a multi-coin blockexplorer.

That said, which blockchain does your transaction belongs to?
It's indicated at the upper-left hand side of the page, just below blockchair's logo; if it's in Bitcoin's blockchain, it should say "Bitcoin transaction".

Electrum isn't a company, it an open-source client which is being developed by volunteer developers.
For reference, here's their license: github.com/spesmilo/electrum/blob/master/LICENCE
In other words, they aren't liable to any lost funds caused by either a bug or a vulnerability in the client.

Electrum isn't a custodial wallet either so there's no way to verify the cause of lost of funds but the user himself.
The users' seed phrase, password, passphrase, etc. aren't stored in any server; the public "servers" are just there to provide Electrum clients data from the blockchain.
Those servers aren't owned by Electrum either, those are by users who have a public Electrum Server.

[1] I can't find any archive or list with that statistic based from 51% attack since AFAIK there's never any successful 51% attack to the Bitcoin network (CMIIAW).
[2] I can't find any archive or list with that statistic based from orphan blocks either since not every Bitcoin node will receive an orphaned block.
[3] There was an incident when bitcoin had to revert back the blockchain due to a serious bug,
during that time, confirmed transactions after the "bad block" had reverted back to unconfirmed. (more info: Value overflow incident)

Additional info for [2] "orphaned block":
We can assume that if a node accepted an (to-be-)orphaned block and if a transaction is included there but not in the main chain
that particular txn can reverse from '1confirmation' into 'unconfirmed' after that node dropped the orphaned block and accepted the valid block.
But since every node isn't the same (location, internet speed, etc.), it only got 1 confirmation in some nodes (minority of the nodes that received the orphaned block)
and not the majority of the network where it's not confirmed.
If the orphaned block and the valid block both contain that transaction, then the transaction will not reverse even after dropping the orphaned block since it's in the valid block too.
So it's a case-to-case basis.

Plus orphaned blocks are uncommon now.

IMO, people (including me) don't like it if a user only quoted a part their post and replied to it without considering the whole post.
So, the quotation of a small part isn't the issue there: it's the reply; as long as it's proper, it's good.

Sometimes, I even -snip- the whole post but keep the [quote][/quote] tags to show that I'm replying to that particular post.

First of all, you should be working on another PC with its own system disk and just mount a clone of the drive where your deleted wallet/keys are.
Writing or installing anything on it can potentially overwrite the very data that you want to restore, including using it as a system disk.

About cloning the drive, I don't have anything to recommend for Windows, I also don't know if Windows' "System Image" is a clone of the whole drive.
If you can restore your Windows Image Backup to another HDD/SSD, do it and try to use that restored copy instead.
---------

After that, download and extract pywallet.py into the same folder where python.exe is located.
Then you can use it without installing anything aside from python v2.x.

The example command in my first post should work but you should change the parameters based from your drive and directory paths and size.

You can launch python from its install directory by using command prompt's "cd" (change directory) command.

Example: if python is installed in "C:/Python/Python27" and python.exe is in that directory, you can enter: cd "C:/Python/Python27"
to set it as command prompt's working directory, then the python command should now work in that session.

If you already set-up a machine with the necessary GPG tools,
you don't have to set it up all over again so there's not much hassle to verify the new version.

Usually, you'll just have to redo the last step which is the actual verification; in the OP, it's the "Download and Verify Electrum" step.

But ThomasV believes otherwise. (ref.)
Because a channel wont automatically change from an active channel into a "static channel backup".

It may be a wallet backup like he suspected, a wallet restored from seed with 'recoverable channel' or restored static channel backup.
But since it's solved already and the issue in GitHub was closed, there's not much reason for charlie574 to clear this up.

You can also try pywallet's --recover tool: https://github.com/jackjack-jj/pywallet
It works just like keyhunter, it will try to restore deleted keys/wallet from the selected drive.

Here's an example command for recover (tested with python v2.7.17 and latest version of pywallet):
Then you'll be prompted for the to-be-created wallet's passphrase (where the keys will be imported) and the deleted wallets'/keys' possible passphrases.
(characters wont display as you type the passphrases)

The result will be a wallet.dat named "recovered_wallet_<number>.dat" that you can load to Bitcoin Core.

If force-close is used, the channel status should also change into "CLOSED" after 1 confirmation of the closing transaction with the label "Close channel <short channel ID>".
And another local "receive" transaction labeled as "our_ctx_to_local <short channel ID>" will be saved and will be broadcasted after a maximum of 2 weeks (last time I tried, it's just 1day).

Hmm, if it showed a green checkmark before, the transaction should've been proceeded with 6 or more confirmations already.
It's very unlikely for a transaction that was included deeply in the blockchain to get dropped so you must have just mistook the icons before.

Anyway, since it was a "blue computer" before you removed it, that means that it's only locally saved in your wallet
either due to dropped/replaced parent transaction, you haven't broadcast it or it's dropped from the selected server's mempool.