[shubhamkmr04]

Part of #1166.

When opening a channel with an exact amount, we checked that our on-chain funds cover the amount plus the anchor reserve, but not the fee of the funding transaction, which is paid from the same funds. Since #1099 lets the caller choose the fee rate, a high one could spend part of the reserve. The LSPS2 service's check before opening a JIT channel has the same gap.

Changes

• Channel opens: with an exact amount, all open_channel variants now also fail with InsufficientFunds if the amount exceeds what the corresponding _with_all variant would fund at the same fee rate. That's Wallet::get_max_funding_amount, which already deducts the fee and the anchor reserves, including the new channel's. Previously, an amount that fit next to the reserve but not next to the fee was accepted. The funding transaction then either spent part of the reserve or, without a reserve, failed to build after the counterparty had accepted the channel.
• LSPS2 service: before opening a JIT channel, the service now does the same check at the ChannelFunding estimate, which is the rate the funding transaction pays. The service gets the fee estimator for this.
• Docs for the exact-amount variants, and CHANGELOG entries.

The maximum assumes all UTXOs are spent, so near the limit it's slightly conservative for wallets with many small UTXOs.

Testing

• open_channel_fee_does_not_spend_anchor_reserve: the wallet holds 1,000,000 sats. Opening 970,000 at 100 sat/vB fails with InsufficientFunds, because the ~15,250 sat fee would leave only 14,750 for the 25,000 reserve. The same amount at the regtest estimate opens and keeps the reserve on-chain. On main, the first open succeeds.
• lsps2_service_funding_fee_does_not_spend_anchor_reserve: the service holds the JIT channel amount plus both anchor reserves plus 100 sats. The existing check passes, but the funding fee doesn't fit, so the service doesn't open the channel and keeps its funds.

Splices are left for a follow-up once #1176 lands, since it reworks the same code. The follow-up covers exact splice_in, and the reserve check when a fee bump falls back to the wallet, as discussed in #1181.

This change was developed with the assistance of Claude Code.

[ldk-reviews-bot]

I've assigned @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.