Fix and improve solo stamping

[Sjors]

Currently trying to stamp with --btc-wallet will fail for two reasons:

1. the signrawtransaction RPC has been deprecated for years
2. it insists on at least two calendars also accepting the transaction

This PR switches to the replacement signrawtransactionwithwallet RPC. It also skips using the calendars when using --btc-wallet.

In addition it adds a --fee-rate argument so you're not dependent on whatever Bitcoin Core decides.

In case the process fails mid way after broadcasting a transaction, as it did before this PR, there's now a way to resume by passing a --nonce and --txid argument. This has the nice benefit of also making RBF possible.

Finally it documents in the README that this functionality exists, but with a warning.

Unrelated, it also adds a --btc-signet option, though at least for stamping --btc-testnet works fine with signet.

Fixes #139 and #140.

[petertodd]

This doesn't actually work as intended. You need to run ots stamp -b --nonce=x --txid=x. If the -b is left out stamping happens normally, ignoring the nonce and txid arguments.

Maybe we want --nonce and --txid to force -b on?

[petertodd]

Another issue we have right now is that if you use the txid and nonce options after a block has confirmed, ots fails to find the new block.

Maybe we could query the wallet for the transaction? Or maybe we also need a block height?

If we have all three options, we probably want to do it via a single --resume option that can find the tx even if the txid changes.

[Sjors]

I added 3123c98 which creates an .ots.pending file with a nonce and txid. It sets --btc-wallet, so that's a step in the right direction. But it doesn't deal with RBF.

[Sjors]

I'm currently testing RBF tracking, will push if it works.

[Sjors]

Alright, added 275e6e5 to track replacements.

I tested both update tracking while in mempool and after confirmation. It's preceded by 9505537 which introduces some test coverage for existing behavior.

[Sjors]

Alright, I had my agent rebase this, address the feedback and make a small improvement based on its experience of accidentally making two transactions because it didn't bother to store the nonce.

The range-diff with my previous version looks sane to me, but it's been too long to remember what I was originally doing :-)

Used this to timestamp the recent Utrecht and Amsterdam municipal election counts: https://github.com/Sjors/verkiezingen-processen-verbaal/tree/master/2026-GR