rpc: Preserve higher locktime when joining PSBTs #35326

This changes joinpsbts locktime selection for PSBTv0 to preserve the highest required locktime.

Currently, when joining multiple PSBTv0s, joinpsbts chooses the lowest nLockTime from the input PSBTs. That can make the joined transaction invalid if any joined input requires a higher locktime, for example through OP_CHECKLOCKTIMEVERIFY.

Example:

PSBT A spends an input that requires nLockTime >= 100 PSBT B spends an input that requires nLockTime >= 105

Current joinpsbts result:

• nLockTime = min(100, 105) = 100
• input B cannot satisfy CLTV

PR joinpsbts result:

• nLockTime = max(100, 105) = 105
• both inputs can satisfy their locktime checks

BIP 174 does not specify joinpsbts behavior. It specifies the Combiner role for merging PSBT data from different copies of the same unsigned transaction, as done by combinepsbt. In contrast, joinpsbts creates a new transaction from distinct PSBTs, so it must choose a transaction-level nLockTime.

BIP 370’s PSBTv2 locktime rules provide useful guidance here: when inputs specify required locktimes of the same type, the transaction locktime is chosen as the maximum required value.

This PR updates joinpsbts to preserve the highest locktime from the joined PSBTv0s and adds a functional regression test with two CLTV-locked P2WSH inputs. The test verifies that the joined PSBT uses the higher locktime and that the resulting transaction is accepted by mempool validation.

Thanks to @nothingmuch for catching this issue.

<!--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/35326.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

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

<!--5faf32d7da4f0f540f40219e4f7537a3-->

This looks closely related to #35100, though I can see this PR as intentionally narrower in scope: a same-type CLTV fix, just more targeted.

That said, I'd like to understand whether that narrower scope is a deliberate choice. As written, this changes joinpsbts to take the numeric max across all PSBTv0 fallback locktimes. That means PSBTs whose inputs are all SEQUENCE_FINAL still factor into locktime selection, even though their nLockTime wouldn't actually constrain the original transaction, and mixed height/time locktimes are still compared numerically without distinguishing the locktime types.

#35100 handles these cases by skipping all-final PSBTs when selecting the locktime, rejecting mixed height/time constraints, and including tests and documentation to match. Are those semantics worth pulling in here, or are they intentionally out of scope for this PR?

I wasn't aware of #35100. Thanks for letting me know. Closing this in favor of that.