It's not necessary bad, security-wise, because it's just the script verifications that are skipped.
Everything in the assumed valid blocks are still being verified by your node.

The topic is quite famous after its implementation so you will find a lot of helpful related topics across the internet.
For example: https://bitcoin.stackexchange.com/a/88666

Must be your RPi's CPU struggling on script verifications after v25.0's default "assumevalid" blocks which is before block height 784000.
Here's for reference: github.com/bitcoin/bitcoin/blob/v25.0/src/kernel/chainparams.cpp#L107C128-L107C128

It's not recommended but if you think it's necessary to speed up your node's IBD, you can set a custom assumevalid block by setting -assumevalid=<block_hash>.

Yes, those are the earlier versions before 0.21.0. (01-16-2021)
Here's the release notes: github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.0.md

To get to the repository's state at that time, click your prefered version's tag above "Compare" button in the 'release' page: github.com/bitcoin/bitcoin/releases?page=2
Example for v 0.20.1: github.com/bitcoin/bitcoin/tree/v0.20.1

All you can do is to wait for them to enable your accelerator-service account.

After that, you'll have to deposit a minimum of 100,000satoshi.
Then paste your TXID on their blockexplorer  (use the "search" feature above their webpage)
In the transaction's 'ETA', click "Accelerate" and you'll be provided with various acceleration options. (the minimum should be enough in most cases)
Finalize it with the "Accelerate" button below.

Just for clarification, is your "Coinbase" the actual Exchange or "Coinbase Wallet" app?
Because you have a chance to CPFP it with the latter.

Contact the seller about it immediately if you're getting "bad-txns-inputs-missingorspent".
There are wallets that will instantaneously remove a transaction that's dropped from its mempool which could lead him to spend its input to another transaction unintentionally.
There also other scenarios that could lead to the same result like its parent transaction that got replaced via rbf.

Since you're the receiver, better maintain your communication with the sender who's in control of it.

Your 'debug.log' file may contain the files names and full path of the recently loaded wallet files
but since you've "shredded" it, there may not be any recoverable data from the drive depending on its effectiveness.
But in order to fully remove the trace, shred the logs as well.

The 'database' folder inside your 'wallets' directory could contain a log file that may contain traces of recently loaded wallets.
The 'settings.json' file may still contain its name if you just deleted the wallet file without unloading it first.
The "Open Wallet" drop-down menu in Bitcoin Core is based from the available wallets in the data directory, so previously used but deleted wallets wont appear there.
The cached data in your RAM wont be an issue after a few minutes.

Other than those, I don't know if there's any other traces of it. (wait for other users' inputs)

CPFP only increases the "effective fee" of the parent and children transactions, not necessarily increases the parent's fee rate.
You can only see that effective fee rate during creation of the CPFP transaction by hovering your mouse over " [→ CPFP " near the fee rate.

Anyways, AFAIK 0.00sat/vB in Sparrow is only possible if the fee rate source is set to "Server" and your selected server "Bitcoin Core" is configured to relay 0sat/vB txns.
If it's the case (not a typo), I'd suggest you to set to standard minimum because even though you're be able to relay such transactions, most of your peers and miners will just reject it.

That is the list maintained by LoyceV, link to profile: http://bitcointalk.org/index.php?action=profile;u=459836
The user is one of the most prominent members here in the forum with lots of good contributions.

As for the list's safety and data integrity, there's no way to verify, but refer to LoyceV's trust rating which is in very high positive standing.

It's quite okay here in the 'Beginners and Help' board since mods aren't too strict to newbies in regards with being off-topic.
But if the provided solution didn't work, I suggest you to open your own topic because the issue may be more than just an unsigned transaction which could require a few more info.

If it requires a new topic, read this topic first (link: Tech Support Help Request Format) and post it in Electrum (link) board.

It's interesting that they've added a gimmick of "additional fee options";
they may have implemented it using prioritizetransaction RPC; because otherwise, they'll need the user's prvKey.

It's nice to let their clients have a sense of control but they might think that the additional fee is applied to the actual transaction.
while in reality, it's only applied as "fee_delta" to mempool_spaces' node and their partner miners that uses it.
When looking on other blockexplorers, they'll still see the original fee rate.
Some may think that they are scammed.

It's not similar to OP's issue.
OP's issue is more of a problem in any of the output's amount which is non-standard for being too low.

Yours is as stated, 'not signed' which is caused by clicking "Add to history" or "save" instead of "sign" in the advanced transaction preview.
To send it, double-click the local transaction and click sign (type your password if prompted), then after signing, click "broadcast".

Yes, it means that your wallet included an already spent or non-existing output in that transaction.

You should also abandon that transaction because it'll prevent any other inputs that it tried to spend to be spent in another transaction.
Right-click on it and select "Abandon transaction".

May be a transaction output or change that got dropped later on, check your transaction list for inconsistencies after the rescan.
You'll see it in the icons which should be a 'check', 'clock' (<6confirmations) or 'question mark', check the ones with question mark icons.

If you want to re-broadcast it and to check what's wrong, go to the "Transactions" tab, right-click on the transaction and select "Copy raw transaction".
Then go to Console and enter the command: sendrawtransaction "RAW_TRANSACTION"
Alternatively, use testmempoolaccept if you do not want to re-broadcast it.
If it shows an error, that is the cause the issue.

In that case, it wont be accepted by Binance as I mentioned in my reply.
Find a way to convert those uppercase characters into lowercase.

The instrcutions are for the desktop version.
In Android, the option is in the settings: Tap the green circle icon -> Tap "Preferences" and scroll-down.
But given the above result, I think that this isn't the cause of the issue.

Having no access to export individual private keys isn't depriving users access to their private keys.
The command listdescriptors true is always available to export the wallet's master private key anyways.
Refer to my post above regarding the reason for removal of dumpprivkey command in descriptor wallets.

For the depreciation of legacy wallets, read this article written by achow101: achow101.com/2020/10/0.21-wallets

Never set it to zero confirmation.
Unconfirmed transactions aren't final and can be replaced whenever the buyer intends to.

Just consider it as a way to save fees on your next payout more than their intended "wait for a lower average fee".
By waiting for other payments to accumulate and be included in that payout,
you'll be saving fees by receiving those all in one payout rather than two or more separate payouts. (considering that the service is legit)

They have a nice explanation in their support page, here: help.sellix.io/en/articles/4805595-scheduled-and-instant-payouts

Have you been scanning the QR code?
Because Binance seems to only support invoices in lowercase but Electrum's QR is composed of uppercase characters.
I tried to paste a full uppercase invoice (converted from a working full lowercase invoice) and the same error showed.

Or manual copy-paste, perhaps?
In this case, Electrum's invoice should be lowercase.
I haven't tried this but it may be caused by them not supporting "On-chain fallback" mechanism to lightning invoices.
So try to untick "Add on-chain fallback to lightning requests" in the small setting icon at the upper-right-hand side of 'Receive' tab.

I think it's because people don't like false advertising.
And calling themselves "Free Transaction Accelerator" for not being a real transaction accelerator is a bad thing, not generally a risk.

Plus, they are accepting donations that received quite a few satoshi.
Newbies who are fond of donating but don't know how accelerating works may think that their transaction that got confirmed through normal network conditions may think that they're the one who done it.
While in reality, its fee rate just made it through the priority to get mined while mempools are low in size.

You still can import but with a different command: use importdescriptors instead.
For a single WIF private key of a Native SegWit address, the command should look like this:
Use: help importdescriptors to know how to use the command.
Here's how to construct descriptors: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md
And to get the checksum (#z0cazjry in the example), use: getdescriptorinfo "descriptor"

---

For dumpprivkey, I believe that it's intentionally removed because of the design of BIP44, BIP49, BIP84 and BIP86 standards which now use non-hardened addresses.
Previously, there's no serious issue with exporting a single private key from a legacy HD wallet with hardened addresses since there's no way to compute the parent extended private key from its pair extended public key and a child (exported) private key.
Now, since the 'address_index' as well as the 'chain_index' (change) paths aren't hardened, that issue is now possible if an attacker gets his hand on the data mentioned above.

There's a workaround to export your privKey but be warned of the issue above:  https://bitcointalk.org/index.php?topic=5449245.msg62109703#msg62109703

You're still in control your keys in your wallet which is stored in your device.
There's no second/third-party custodian that hodls it for you.

I tried it in testnet Electrum that is connected to their server: electrum.blockstream.info:60002;
And it does accept replacement transactions even without the opt-in RBF flag.

Considering Electrum mainet and testnet works similarly, it may actually work depending on blockstream server's node in mainnet.
Creating the replacement transaction for full-rbf cannot be done in Electrum GUI though. (for now)

Here's the test transaction: https://mempool.space/testnet/tx/85161f67da19ab4715e6ade401ecedb5fdda2eceb84ac4b9d2663e6952ca6aa8
Didn't opted-in for RBF but tagged in mempool space as "full-RBF",
BUT, despite being broadcasted successfully, the lower fee rate transaction is the one that's mined,
probably because it didn't made it in or rejected by the miner of the next block's mempool.

-edit-

I've tried it and their mainnet counterpart accepts full rbf as well.