rpc: Let dumptxoutset fail early on stale targets and concurrent runs #36266

This improves handling of two edge cases where dumptxoutset currently only fails after doing unnecessary and possibly incorrect work:

Stale rollback target (first commit): ParseHashOrHeight accepts any known block hash, and the rollback path never checks the target is on the active chain. The full UTXO set is copied and blocks are disconnected back from the tip only to fail when the target block height is reached. This is now rejected before all that as an invalid param, matching the check in getchaintxstats and scanblocks. This is a pretty unlikely scenario but the fix is also very small.

Concurrent calls (second commit): Nothing prevented triggering two runs at once and since this is a relatively long running operation I don't think it is that unlikely that this might happen by accident or that users think this might actually be a possible thing to do if you want two different dumps. On master currently both runs would write to <path>.incomplete, so the second dump to the same path corrupts the file the first one reports as successfully written. And also the prune lock has a fixed name, so the second run overwrites the first's height and the first to finish deletes the others lock mid-rollback. A second call now fails immediately with "dumptxoutset is already running". TemporaryPruneLock is extended and renamed to DumptxoutsetGuard and handles both the general running of multiple instances and the lock management. The alternative to this approach would be to allow for concurrent runs and fix that behavior but it seemed to me like that would be overengineering considering that the audience for this functionality should be very small.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36266.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

LLM Linter (✨ experimental)

Possible typos and grammar issues:

• // The prune lock must be gone before the next run can register its own -> // The prune lock must be gone before the next run can register its own lock [the sentence is incomplete as written; the missing noun makes the comment unclear]

^{2026-09-16 07:25:53}