#34534 rpc: Manual prune lock management (Take 2)

• Prevent needed blocks from being pruned when external or offline wallets are temporarily unloaded
• Allows wallets to rescan against pruned nodes without having to manage full manual pruning logic

This pull request adds `setprunelock` and `listprunelocks` RPCs, alongside a `-prunelockheight` startup option, to allow manual control over the node's block pruning locks. It exposes the internal BlockManager prune lock system to external wallets and scripts to keep blocks from being pruned while a wallet is temporarily unloaded.

Problem: On pruned nodes, if a wallet is not loaded while the node runs, blocks necessary for rescanning that wallet later can be deleted. External wallets using bitcoind as a backend also lack an explicit mechanism to lock block heights without reimplementing automatic prune management using `-prune=1` and manual `pruneblockchain` calls.

P3 · new feature

• P3 because it adds RPC methods solving an operational limitation for external wallets on pruned nodes
• Addresses real wallet rescan issues, but downstream tools are not actively blocked waiting for it

P3 because it introduces new RPC methods that address a real operational limitation for external wallets running against pruned nodes. While achow101 and stickies-v endorse the use case for wallets, downstream applications have not actively queued up demanding this specific interface, making it worthwhile but deferrable.

Membership: Adds `setprunelock` and `listprunelocks` RPC methods in `src/rpc/blockchain.cpp` and carries the `RPC/REST/ZMQ` label.

Factors: security/stability 0, bug 0, performance 0, user value 2, leverage 1

P3 · new feature

• P3 because it hooks into existing block storage prune locks without changing validation rules
• Held locks can cause disk consumption to temporarily exceed configured prune targets

P3 because it affects `BlockManager` pruning behavior and could cause disk consumption to exceed `-prune` configurations if locks are improperly held. It hooks into existing prune lock logic rather than changing consensus or validation rules.

Membership: Touches `src/node/blockstorage.h` and adds an option that alters when block and undo files can be pruned by `BlockManager`.

Factors: security/stability 1, bug 0, performance 0, user value 1, leverage 1

• Ready for review; CI passes and earlier reviewer feedback has been addressed

Code is rebased, tests and CI pass, and feedback from reviewers has been addressed.

Author status: active

Open concerns:

• Andrew Toth questioned whether the motivation is compelling given that existing manual pruning with `-prune=1` and `pruneblockchain` can defer pruning until rescans finish.

Resolved concerns:

• luke-jr requested changes on returning an object rather than an array in `listprunelocks` for future extensibility, which was implemented.
• sedited raised concerns about thread safety when copying prune locks in the RPC, which was fixed with an explicit container copy inside `cs_main`.
• rkrux suggested documenting that `-prunelockheight` can cause `-prune` targets to be exceeded, added release notes, and requested test coverage for wallet rescan scenarios, all addressed by the author.

• Generally positive sentiment on supporting unloaded wallet rescans
• Concept approval for the unloaded wallet rescan use case (stickies-v)
• Approval after thread safety feedback was resolved (sedited)
• Questioned whether existing manual pruning options already suffice (andrewtoth)

Positive; sedited approved and stickies-v gave Concept ACK, while andrewtoth questioned whether existing manual pruning suffices.

Reviewers who engaged on implementation have approved or had their requests addressed. Andrew Toth questioned the necessity versus existing manual pruning options, which the author answered, but no formal objection or NACK was raised.

• sedited approved the PR: 'Re-ACK 9fa4953f01cab3ab8669b316224b4eeb8433a8d8'
• stickies-v Concept ACKed after achow101 detailed the unloaded wallet rescan use case
• andrewtoth asked whether '-prune=1' and 'pruneblockchain' could achieve the same goal, which fjahr addressed by explaining the burden of managing disk thresholds in client wallets

Review verdicts (DrahtBot): 0 (+1)

• Stale ACK: sedited
• Concept ACK: stickies-v

File list not available for this run.

This PR adds `setprunelock` and `listprunelocks` RPCs, alongside a `-prunelockheight` startup option, exposing the existing blockstorage prune locks mechanism to external users and tools. It prevents blocks necessary for future rescans from being pruned away when wallets are not continuously loaded on pruned nodes. Reviewers sedited and stickies-v have supported the approach while andrewtoth questioned whether existing manual pruning could suffice. The branch is clean, fully tested, and ready for review.