It's not possible to do to existing transactions in mempools since the field that signals for opt-in RBF is in each input's nSequence field.
Changing it into 0xfffffffd or lower will result with "mandatory-script-verify-flag-failed" error.
Changing nSquence will also result with a different txid.

Applying those changes to an existing unconfirmed transaction to flag opt-in rbf will result with a different transaction,
basically replacement that even full-rbf nodes will reject for having the same fee as the original.

The suggested full-rbf above is the solution since it doesn't require that flag to be replaced
but the replacement need to follow replace-by-fee rules like paying for its own and the original transaction's bandwidth.
(e.g.: if size are the same; +1sat/vB minimum by default)

To try in mainnet, you need to find a way to connect to nodes that enabled full-rbf to broadcast the replacement transaction.
Example (Needs a Bitcoin Node): https://petertodd.org/2023/why-you-should-run-mempoolfullrbf#full-rbf-peering

Use testnet on a wallet that can create transactions with disabled opt-in rbf flag.
However, you may not be able to accurately test full-rbf's behavior in testnet because the number of nodes that enabled -mempoolfullrbf is entirely different in mainnet.

Okay that works too, but you should've just use sweep to your Electrum wallet created with your Ledger Nano,
That's much simpler than creating a new online imported wallet with the private key.

The whole reason why cold-storage setup is recommended by the majority is for the safety of your coins while sending the bitcoins in case your PC is compromised.
It's not simple but the "air-gap" offline machine where the private key will be exposed is impervious to most hacking attempts.
Considering the amount contained in a Casascius Coin, I'd still wont recommend sweeping the private key on an online machine.

"Offline Electrum wallet", yes, what you need is to create a new 'imported' wallet containing the private key.
This wallet is only required to sign the transaction that you'll create in the online Electrum wallet.

During the step when sending a new transaction in the 'Send' tab of online Electrum wallet.
That'll be your recipient "Pay to" address.

Try to click their dedicated "refresh" (circular arrow) button on the upper-right (not the browser's refresh button).
It'll trigger a full recan for wallet-related transactions using their wallet API.

How about the output, is it unspent yet?
Check your Transaction history by clicking "Bitcoin" on the left-hand side and see if there's no unfamiliar outbound txn in the transaction history.

In you offline machine, proceed to create a new wallet and select the option "Import bitcoin address or private keys" and paste your prvKey there.
Your Casascius' mini-private key is supported by Electrum and wont be needing additional prefix since the address is legacy.

In you online machine, do the same procedure but import the address instead of the mini-private key.

Then you can follow the same cold-storage setup procedure to create, sign and broadcast a transaction that'll send the entire funds to your Ledger.
I noticed that the video is old, in the new version, you can export/import PSBT transactions as file via "Share->Save to file".
Note: Confirm every character of the address before broadcasting the finalized transaction.

You can always work on a backup rather than the original wallet.dat file.

In the future versions, yes.
In not-so-distant versions of Bitcoin Core, you wont be able to load old bdb wallet.dat files without upgrading it first into sqlite.

Here's the proposed timeline with checklist of the implemented parts: https://github.com/bitcoin/bitcoin/issues/20160

Looks reasonable enough, but I will still wait for an official response from OP.

Based from his reply about using a library, it seems like OP is asking this for software development reasons rather than practical.
So it's better to tell him how it works more than how to do it with various wallets.

Please explain this better because I can't make sense of "x fees" and "actual x+10 fees".
In bitcoin, the fee is the excess amount from the inputs and outputs, it's not something that's included in the transaction data.

Also, what they mean by "replace" is an actual replacement of the already-broadcasted transaction, it's not a simple change of values to an existing txn.
In other words, you'll have to create a new transaction that spends a least one of its input and sign it with the necessary privKey.
Read BIP-125 for more information: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
Take note that some nodes do not require that "signaling" and will accept a replacement so you can try it regardless as long as you relay it to a full-rbf node.

In your replacement transaction, you'll have to either reduce the existing output's amount (preferably the change)
or add additional input and set the output(s) and change accordingly.

Take note that the suggested coin control has to be used beforehand because by using "!', Electrum wont use its balanced size-privacy oriented coin selection algorithm.
It will use all of your available UTXO is that transaction.
And even if you do not worry about privacy, it could create a transaction with high transaction fee for using too many inputs in some cases.

You mean inside the same directory where seedrecover.py is located?

If not, it should be inside it if you do not want to include the full path.
If yes, one possible scenario is if your Mac is configured to hide file name extensions, in which your "token.txt" file could actually be "token.txt.txt" file.
In that case, enable file name extensions (Google how) to see if you've actually named like that.

Yes, use "pay to many" and "coin control".

Coin control isn't mandatory but useful in this case if you have lots of UTXO.
Learn how to do it here: bitcoinelectrum.com/how-to-spend-specific-utxos-in-electrum/

Then, for using specific change address:

• After selecting the coin with enough bitcoins that you want to spend,
• Go to 'Send' tab, click the small setting icon on the top-right and tick "Pay to many".
• In 'Pay to', paste your preferred change address as one of the recipient with amount of "!", for example: tb1q39wfap3srjnpjtap6lhfj06mwymdz4e42u0e47,!
• Press enter to add a new line and paste the recipient's address with the amount that you want to send, for example: tb1qcku7kepqvj88lz9gd7ac3uhzszfsve3uwypts4,0.00012345
• Then, proceed to the usual sending procedure.

For reference: Based from the example, 'Pay to' field should look like this:

Now, it propagated again.
Those nodes that dropped it from their mempool for being way below their maxmempool must have accepted it back from nodes that kept it.

It's opted-in for rbf,
If you're willing to bump the fee to at least 2140satoshi (16.1sat/vB), it'll be accepted by ViaBTC's free accelerator: viabtc.com/tools/txaccelerator/
That's about 554 satoshi to be deducted from the already small output.

After that, it would only take about 10~60minutes or more to get a confirmation, until they mined a block.

The advice isn't about performing something to the existing transaction since it's never even mentioned in my reply.
It's for information and an idea that he can follow in his future transactions to save on fees.

Notice that I followed-up his "should have" scenario with another "could've".

Or you could've used "coin control" features because the intended 0.00013281BTC output can be paid by any one of those 7 inputs used.
That way, it wouldn't be expensive to bump the fee rate effectively or you can even initially set a high fee rate without resulting with a very high absolute fee.

Here's how to use coin control: bitcoinelectrum.com/how-to-spend-specific-utxos-in-electrum/
Additionally, you can also freeze UTXO in the coins/address tab.

For your information, it used all those "unnecessary" inputs because of Electrum's privacy feature that made it spend all the available UTXO referenced to the same address so that it wont be linked with other UTXO in the future.
Given that, also use coin control in order not to do so.

How many "unconfirmed parent" transactions are these?
Based from the context, those must be a result of your previous transaction's change being used as input by your next transaction.
(repeat in the next transactions)

So, the broadcast error might not be a simple "not 1sat/vB higher than the original"
but a case of "you'll have to pay the total fee of all the transactions to be replaced".
Means that if the transaction that you're trying to bump with RBF is the parent of your other transactions, it also has to pay with at least the total absolute fee of all of its children txns and Electrum doesn't add that requirement by default, only the mandatory additional fee that'll pay for its bandwidth.

If you successfully set the required fee and broadcasted it, its children txns will be invalidated by the replacement.
So consider it if those other payments are important.

The best course of action is to identify which is the latest child transaction among those "unconfirmed parent" transactions. (look at the balance next to amount)
Then, bump that child with a very high fee that'll make miners consider including its parent transactions to their block (basically a manual CPFP)
Without the txids, only you can compute for the best fee rate to use.
But based from the current state of mempools, now is not a good time to bump unless you're in a rush.

If you're using their mobile app, it'll show under "Network fee" after tapping "Next" when sending.

There's a tooltip button (!) there that explains what is it and in that tooltip, there's also a "Learn More" button that explains it further.
The fee rate they set is based from their perspective on what's currently optimal and today is not a good time for low value transactions.

So in other words, you received that $6 in a single transaction?
If so, that's good since your transaction's size will be low that'll result with lower absolute fee.

$6 worth of bitcoins is more or less 0.00016020BTC.
The dust limit is 0.00000546BTC for legacy or 0.00000294BTC for SegWit if it's following the Bitcoin standards (Trustwallet's limit isn't disclosed)
So if you deduct the fee that's set by your wallet, it will fall way below the dust limit.

Wait for the Ordinals NFT hype to pass until you can spend with 1~5sat/vB fee rate; use another wallet to do so.

Also, have your received that $6 in one transaction?
Because if not, you'll have to spend more on fees than the actual amount that you can send.

Use the best one that you have, for reference, my quite old i7 4790 can only do 3.9k P/s (Passwords per second)
With that, it could take a week to go through all the possible combinations.
Besides, the correct password may be found near the start, mid or last part of the search, so the actual time still depends on luck.

To test your best processor's capability, you can test it with the command:Make sure that the selected wallet is your actual wallet file or has the same version.

Then make a rough estimate on how long it would take to exhaust all of the possible combinations with that rate.
Take the maximum number of combinations that you can search: ¹⁵P₈ plus ¹⁵P₉ is equal to 2,075,673,600 combinations.
Let's say that your processor can do 10kP/s which is equal to 10,000 passwords per second, it will take: 2,075,673,600 / 10,000 = 207,567 seconds (58hours) to exhaust all those combinations.
If you're lucky, you might found it at the first hour or if you're not, right after 57 hours.

Have you used any special or unique methods to derive your 8~9character password from the 15characters?
If yes, then it wont be possible without knowing the exact method that you've used.

Or have you picked random 8 or 9 characters from those 15 without using duplicate?
If yes, bruteforcing an 8~9 character password with BTCRecover from 15 characters is quite doable with roughly, ¹⁵P₈ plus ¹⁵P₉ maximum number of combinations.
But you need a fast processor for this since it may take months with old generation processors, plus it wont work with GPU.

For the setup, read through the updated version's official documentation: https://btcrecover.readthedocs.io/en/latest/INSTALL/
Then, the usage: https://btcrecover.readthedocs.io/en/latest/TUTORIAL/
(DYOR since it has all the info you need)

And here's a short guide for your case:

• Your "tokens.txt" should compose of your 15 character long password, one character per line.
• You would need to add --length-min 8 --length-max 9 to specify that your password can only be 8~9characters long.
• Due to the billions of possible number of combination, you may have to add --no-eta -d to skip the initial password counting procedure.

Here's an example command:

It's actively being updated in the dev branch: https://github.com/goatpig/BitcoinArmory/commits/dev
But I don't know if there's an exact date on the new release version yet.

Yes, it wont work without the blockchain so you may have to choose from any of the famous SPV wallets that don't require a full Blockchain.
A few suggestions are: Electrum and Sparrow.

Or use Bitcoin Core itself with "pruned" blockchain by setting your desired size during initial setup.
It wont store all the Blocks in your disk but still download and verify all of those blocks since it needs full validation. (it will delete older blocks to accommodate the size)
The downside of this is you can't do anything that requires the blocks that are already deleted.