Does the error includes any "Debug message" below?
If there is, enable logging so you can see the full error in your debug log.

You can enable it in: "Tools->Preferences->Misc->Write logs to file" (requires an app restart)
Then you can access the logs in electrum data directory, "logs" folder.
If nothing works, it might be an error worth reporting to the developers or Electrum or Ledger.

Bitcoin Core has to be restarted in order for the new config to apply.

Also, are you using Bitcoind or Bitcoin-qt, have you set the data directory via the GUI?
Because depending on the setup, Bitcoin core may not be loading your bitcoin.conf file in the default data directory.

You can save the copied text onto a txt file or none, the important thing is the contents.
And send it to your offline Electrum, open the file "as text" or open using a text editor app and then copy its contents.

Is the offline Electrum also Android?
If so, you can import it via "Send->Paste", then you can proceed to sign and broadcast the transaction.
If Desktop, use "Tools->Load transaction->from text".

This will never work in Electrum since the derivation path that you can edit only applies up to the BIP39's account index.
Any additional derivation paths will work regardless despite being non-standard.

Whatever the derivation path that you've set,
Electrum will follow it up with internal/external index (for receiving and change path), then the "address_index";
both are hardcoded to be unhardened.

No.
It's mainly developed for the puzzle transaction which is Bitcoin-exclusive.
Example:
Result:

What's your goal anyways, depending on it, I may know an alternative that'll work in Ethereum.

After figuring-out the correct way to set-up, create a MultiSig wallet in Electrum testnet.
You can start Electrum with --testnet command line parameter to start it in testnet, then claim testnet bitcoins from testnet faucets to use for your tests.

But if you really insist on testing it in mainnet, you'll need a fully synced Bitcoin Core with preferably full blockchain.
Create your transactions in Electrum, completely sign it.
But instead of broadcasting the transaction(s), open Bitcoin Core and use the command testmempoolaccept to see if your node will accept it without actually broadcasting the transaction.
About the command: https://bitcoincore.org/en/doc/24.0.0/rpc/rawtransactions/testmempoolaccept/

Yes, but it can only create up to 20 (/your gap_limit) unexpired unpaid invoices, further addresses will require you to accept a warning message.
If you accepted it, Electrum will let your generate more receiving addresses despite of the previous 20 being empty.

And uif you're going to rely on the receive tab for new addresses, you must use the invoice's expiration option properly,
If you set it no "never", Electrum will never reissue that address the next time you generate an invoice unless you delete the invoice.
If you set an expiration, the wallet will reissue the receiving address of the expired invoice next time you request for an address but only if it didn't received bitcoins yet.

Take note that the ones that have expiration are the invoice, not your addresses.
You can still use them regardless of the invoice's state.

It'll show "Unconfirmed" if it's unconfirmed, "Local" means that it's only saved in your wallet, your selected server dropped it from their mempool.
Even if it's "local", Electrum will allow you to perform RBF if you've set that transaction as replaceable.

So, you have two choices:

• 1. You can Right-click on it and check if there's an "Increase fee" option.
  If there is, use that to set a higher fee rate.
• 2. There's another option for local transaction which is "Remove",
  that will enable you delete that local transaction from your history to spend its input(s) to another transaction.
  Use this if you want to change the recipient's address.

Electrum has such built-in feature. In the console, use the command convert_xkey()
Example:
If you're using the daemon:

Although, I'd not recommend that method aside from recovery purposes like restoring another wallet to Electrum.

Puzzle numbering starts with '1' (1BgGZ)
But in Bitcoin's blockchain, output_index starts with '0'.
So you're looking at the wrong puzzles, you must be talking about puzzle number 130, 135, 145, 150, 155, 161 respectively.

The reason why those have spent outputs already is because the owners decided to reveal the public keys of puzzles divisible by '5' as "bonus".
They didn't spent the puzzle's UTXO but sent and spent another set.
For 161, 161~256 are spent because the owner (not the OP) agreed to a comment that those are computationally impossible to bruteforce.

You can use iancoleman's BIP39 tool; but do not trust, validate it; it's open-source so you can ask someone in your company to audit its code.
Link to the source code: https://github.com/iancoleman/bip39

In Bitcoin Core:
Use the console command that I've suggested with "true" flag.
Open the menu: "Window->Console", select the correct wallet in the console's wallet selection drop-down menu
Then use the command: listdescriptors true

Take note of the results, you need to find the correct parent descriptor among the results that can derive the funded address' private key.
If your address starts with "bc1q" (default), get the descriptor that shows: "desc": "wpkh... and "internal": false,.
The latter tells that the descriptor is for your receiving addresses and the former shows that the script type is for bc1q addresses.
If the address starts with '1', then get "desc": "pkh...; if '3', then "desc": "sh(wpkh... (should be internal false for both).

In BIP39 Tool:
Open it in your "Air-Gap" machine's browser.
Paste the descriptor's master private key in the "BIP39 Root key" text box ("xprv..." do not include the following ' / ' and the rest),
scroll down a little and open "BIP84" tab (for 'bc1q'  address) / "BIP44" tab (for '1'  address) / "BIP49" tab (for '3' address)
The default derivation paths of those tabs should match to the descriptor's path so the addresses and keys should be listed below the page.
You can click "show ___ More rows" below the addresses to generate more addresses if it's not included there.

Electrum will derive the child key of the provided master private key with the derivation path of m/0 (receiving) and m/1 (change) which is different than the descriptor's derivation path.
And with that restore option, the user can't select the path Electrum should use.

Quite sounds like it, although some parts of the OP suggest that there are two consolidation transactions.
Maybe OP is misusing terms.

@BGK045 We need clarification, it's better if you can share the transaction(s) if privacy isn't your main concern.
Or just follow this posting template: [READ BEFORE POSTING] Tech Support Help Request Format

Descriptor wallets do not support dumpwallet command.

Use listdescriptors false instead,
you can change the arg to "true" to show the "master private key" instead of the "extended public key" in case you need to derive the address' private key.
But that wont output the addresses directly, you need to derive them using tools or restore it to other wallets.
What are you trying to do exactly? Newly created wallet with large balance... sounds "interesting".

Also, I suggest you to create your own topic to answer that question above, since there seem to be more of it than using that command.
Another note, do not entertain any PMs that you'll receive, keep the non-private conversation public as much as possible.

It will work with or without the .txt file extension.
The only difference will be the compatibility of the output with certain txt editor applications.

That is Sparrow's privacy feature that tells you that it's a "reused address" which can be bad for your privacy.
It wont have any effect on transaction signing.

At least you now have the option to restore the seed to a cold-storage set-up with that 'script type' and 'derivation path'.
It is arguably safer than your Ledger if everything is setup correctly.

If nothing worked, you can consider it via Electrum: https://electrum.readthedocs.io/en/latest/coldstorage.html
Make sure that the offline machine is Air-Gap: Air-Gap Wikipedia
If you do not plan to keep it, zero-fill the drive of the Air-Gap machine after signing the transaction.

Maybe it's the other way around, you might have spent the output of the other consolidation transaction but it didn't appeared in Sparrow.

Other than that and the previously mentioned possibilities, those are the only reasons I can think of.
That's unless the two consolidation transactions' receiving addresses aren't actually the same.
With that, there could be a couple of more reasons why the other one didn't appeared like it's not yet generated in Bitcoin Core's keypool.

Since it's the same address and only one transaction appeared,
Bitcoin Core might have missed the other transaction or currently do not have the block where that transaction is included.

If it's currently syncing, wait for it to sync.
If Bitcoin Core has already caught up already to the tip of the blockchain, perform a rescan using rescanblockchain command in the console. (this could take a while)

If your blockchain is pruned, you can only rescan specific blocks that aren't pruned yet, query the 'pruneheight' using getblockchaininfo command.
Additionally, if the missing transaction belongs to the pruned block, Bitcoin Core wont be able to scan it without syncing from scratch.

Right, I forgot about it. It's been a while since my last wallet setup in Sparrow.

I've edited that part from step 10 to step 9.

Folow the guide in o_e_l_e_o's link but in step 6,
select the correct "Script Type" that corresponds to your address type.
If the addresses start with '1', select "Legacy"; if '3', select "Nested SegWit"; if 'bc1q', select "Native SegWit" and if 'bc1p', "Taproot".

Take note that step 7 has wrong image (duplicate of the last step's image), "Connected hardware wallet" is among the keystore options below the previous step.

In step 9, change the derivation path to m/44'/5757'/0' first, then click "Import keystore".

For your 100000sat to be all spent as fee, you're looking at a fee rate of around 900sat/vB (SegWit 1in-1out transaction)
As long as the future wont be stuck at that ridiculous fee rate range, your paper wallet wont be worthless.

If the future's mempool condition is your concern, then it depends on the future implementations and adaptation of the second layer.
If things will be the same, it wont be too different from today's condition, if not only a bit higher/lower.

If the fiat price is your concern, then the price of the fee will increase with your paper wallet's price.
In this case, you're worrying for nothing because for example, a 400sat absolute fee will still be 400sat even if Bitcoin's price increase, only its fiat equivalent.

By following that method, just make two copies of the PSBT with 1 signature and send each to the other two cosigners.
Either one should be able to sign it.

Check each cosigner wallets' addresses if they are all the same, then go to each cosigner's menu: "Wallet->Seed" if the seed if correct.