fix: rescale HTLC in-flight caps on splice promotion

[martinsaposnic]

Summary

Fixes HTLC-in-flight caps not being recomputed on splice promotion. Without this, any HTLC larger than the pre-splice channel's advertised cap is rejected after a splice-in, breaking LSPS4 JIT splice flows.

Symptoms observed

• Sender: HTLCMaximum inside send_htlc, surfaces as TemporaryChannelFailure(0x1007) to the payer.
• Receiver: Remote HTLC add would put them over our max HTLC value (<pre-splice cap>), force-closes the channel.

The receiver case is the severe one: channel lost along with any pending fees.

Root cause

On splice promotion (the core::mem::swap(&mut self.funding, funding) in channel.rs), holder_max_htlc_value_in_flight_msat and counterparty_max_htlc_value_in_flight_msat stay pinned at their pre-splice values. The assumption that channel_value is immutable no longer holds once splicing is in play.

Fix

Rescale both caps proportionally to the channel-value change on splice promotion.

Test change

Also tightens test_splice_in's post-splice assertion. The existing check was assert!(htlc_limit_msat > initial_channel_value_sat) which compares msats to sats and passes vacuously even with the bug.

E2E validation

Reproduced on regtest with LSPS4 JIT splice:

amount	status
3x small (200, 400, 800 sat)	pass
80k sat (triggers splice, grows channel 50k -> 167.6k)	pass
3x small (300, 600, 900 sat)	pass
120k sat (second splice, grows channel 167.6k -> 344k)	pass

Without the fix, the 80k and 120k payments force-closed the receiver's channel.

Checklist

• cargo check -p lightning passes
• Reproducer validated on regtest with LSP + embedded LDK node (both sides must have this fix)
• Upstream version of this fix to be filed separately at lightningdevkit/rust-lightning