Build splice_in_with_all from manually selected inputs

[jkczyz]

Fixes #1168.

Node::splice_in_with_all estimated the maximum amount with a wallet drain and then ran coin selection for that exact amount. The resulting contribution had at most the anchor reserve as a change output, so bump_channel_funding_fee had nothing else to pay a higher fee from. With anchor channels enabled, the bump shrank the change output and spent the reserve on the splice fee. Without a reserve there was no change output at all, so the bump failed with ChannelSplicingFailed. The drain estimate also ran at the funding feerate estimate while the contribution could be built at a pending splice's higher RBF minimum.

This PR instead hands LDK the wallet's confirmed UTXOs as manually selected inputs (FundingBuilder::add_inputs). They are consumed in full with no change output, the amount added to the channel is whatever remains after fees at the template's feerate, and a later fee bump is paid by adding a little less to the channel. When an anchor reserve is required, it is kept as an explicit output back to one of the wallet's own addresses, which stays fixed across bumps.

The reserve address is marked used in BDK as soon as it is handed out, since the splice transaction only reaches the wallet once negotiation completes and until then BDK would offer the same address as change elsewhere. The mark is dropped again if the contribution cannot be built, or via DiscardFunding if LDK rejects it.

Insufficient-funds checks stay in front of LDK, which would otherwise build a near-empty contribution. The drain-based splice estimate is removed along with the shared-input handling in the drain helpers that only it used.

The first commit extracts the low -incrementalrelayfee bitcoind setup used by the splice RBF tests into a shared helper, since the new tests need it too.

Tests

• splice_in_with_all_bump_fee_retains_anchor_reserve: splice in with all funds with an anchor reserve, bump the fee, and check the bump succeeds, the amount added to the channel drops by exactly the fee increase, and the on-chain balance after confirmation still holds the reserve.
• splice_in_with_all_bump_fee_without_anchor_reserve: same without a reserve, where the bump previously failed outright.
• A wallet unit test for the confirmed-input listing (unconfirmed outputs excluded) and one for the address reservation (skipped while reserved, offered again once released).

Both integration tests fail on main: with a reserve the bump leaves the spliced-in amount unchanged while the fee rises, i.e. it is paid from the reserve; without a reserve bump_channel_funding_fee returns ChannelSplicingFailed.

🤖 Generated with Claude Code

[ldk-reviews-bot]

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Seems Leo's suggestion here might make sense to add in this PR?: #1103 (comment)

[tnull]

Codex:

1. [P2] Preserve small configured anchor reserves — src/lib.rs:1891 (/home/tnull/workspace/ldk-node-review-pr-1176-0T4Hm0/src/lib.rs:1891). With
   per_channel_reserve_sats = 546, this condition omits the reserve output. Because the previous balance check was removed, splice_in_with_all now succeeds
   and drains the wallet to zero sats. Preserve positive reserves using the destination’s dust threshold, or reject the splice when preservation is
   impossible.

[tnull]

Codex:

2. [P2] Report fee shortfalls as InsufficientFunds — src/lib.rs:1970 (/home/tnull/workspace/ldk-node-review-pr-1176-0T4Hm0/src/lib.rs:1970). With 26,000 sats
   confirmed, a 25,000-sat reserve, no local channel balance, and a 2,500 sat/kwu feerate, LDK rejects the contribution before the subsequent insufficient-
   funds check. This mapping returns ChannelSplicingFailed, preventing callers from identifying the funding shortage. Map ManuallySelectedInputsInsufficient
   to InsufficientFunds.

[tnull]

CI is failing, not sure if flake:

thread 'splice_rounds_discarded_while_the_channel_is_listed_fail_at_close' (307885) panicked at tests/integration_tests_rust.rs:4488:5:
assertion `left == right` failed: the bump reused an input of the first round
  left: [OutPoint { txid: ec9c78fceb249288b98f6b1772c1b2b648178638e4799baeae8a6b086af0c555, vout: 1 }, OutPoint { txid: ec9c78fceb249288b98f6b1772c1b2b648178638e4799baeae8a6b086af0c555, vout: 0 }]
 right: [OutPoint { txid: ec9c78fceb249288b98f6b1772c1b2b648178638e4799baeae8a6b086af0c555, vout: 1 }]
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    splice_rounds_discarded_while_the_channel_is_listed_fail_at_close