bump_channel_funding_fee can't bump a splice_in_with_all splice without spending the anchor reserve #1168

splice_in_with_all estimates the maximum amount from a wallet drain and then runs coin selection for that exact amount. The resulting contribution has at most the anchor reserve as a change output, so bump_channel_funding_fee has nothing else to pay a higher fee from:

• With anchor channels enabled, the bump succeeds by shrinking the change output, i.e. the anchor reserve is spent on the splice fee. The reserve is enforced for on-chain sends and at splice time, but not here.
• Without a reserve there is no change output. LDK keeps the value added fixed for coin-selected contributions, so it refuses the in-place fee increase and falls back to coin selection. The wallet has no other confirmed inputs, and the original ones can't cover the same amount at a higher fee, so the bump fails with ChannelSplicingFailed.

For a splice-in of all funds the right outcome of a bump is to add a little less to the channel. LDK already has a mode for that: manually selected inputs (FundingTemplate::splice_in_inputs / FundingBuilder::add_inputs). The inputs are consumed in full with no change, the value added is derived from the input total minus fees, and a fee bump of such a contribution is paid from the channel side, so bump_channel_funding_fee lowers the contribution instead of failing or dipping into change.

Proposal: build splice_in_with_all from the wallet's confirmed UTXOs as manually selected inputs, with an explicit output back to our own address for the anchor reserve when one is required. That output stays fixed across bumps, so the reserve is preserved there too. This also removes the drain-based amount estimate, which currently runs at the requested feerate while the contribution may be built at a higher RBF minimum.

Things to check while implementing:

• how the funding-payment classification treats a splice-in with an output back to our wallet (amount and direction come from the contribution's net value, so they should be unaffected);
• keeping an explicit insufficient-funds check in front, since LDK will otherwise build a near-empty contribution;
• the per-input previous-transaction size limit (PrevTxTooLarge) applies to both modes and isn't new.

Found while reviewing #1159.