splice_locked + channel_reestablish bug fixes

[wpaulino]

This PR features commits to fix three different issues found by the chanmon_consistency target around the interaction of splice_locked and channel_reestablish. It fixes the following payloads from #4363:

2a24b7a4b7a3ffabacb2bc41bcffffbc0facad3cfffffe01080000bcbc
2a24b7a4b7a3ffabbc41bcacb2ffffbc0facada3ffabbc41bcac00bcbc
2a24b7a4b7a3ffabacb2ffbc0facadfcffffffbc28a6bcffffffac1d00
3124b7a4b7a3ffffbcacbcffbc0fadabffbca6bcacadffffffbcbcffbc
2a24b7a4b7a3ffabacb2bcffbcffffbc0facadffffb8ff21bdffbcbcbc
2a24b7a4b7a3ffabacb2bc41bcffffbc0facadff08bcfffe000100bcbc
2a24b7a4b7a3ffabacb2bcffbcffffbc0facadc1a3ffabacb2bcffbcbc
2a24b7a4b7a3ffabacb2bcffbcffffbc0facadffffffabacb2bcffbcbc
3126b7a4b7a3ffaba6adbcffbcffbcbcad0faca6ffbcffffffbcbcbc
3124b7a4b7a3ffff24b85dabffbcadffbc0f1e1118acadffff0cffbc71
b4a6ffacffbcada1ffb8
ffa3ffacffbcadff
b4a6ffacffbcadfff1ff
b4a6ffacffbcadff11bc
b4a6ffacffbcadffbcbc
b4a6ffacffbcadff0cbc
b4a6ffacffbcadffabff
b4a6ffacffbcadabffa4
b4a6ffacffbcadffffb4
a4a6ffacffbcadfff1ff
b4a6ffacffbcadc4ffbc
b4a6ffacffbcadacffbc
b4a6ffacffbcadffacff
55a0ffabb4ffb4ac26ff
55a0ffabffb4ffb4acff
7aa4a6ffabb4ffb4acff
55a0ffabb8ffb4acff

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt 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.

[ldk-claude-review-bot]

This or_else fires whenever the first closure returns None, which happens not only when self.pending_splice is None (the intended case per the comment), but also when self.pending_splice is Some and sent_funding_txid was filtered out because it matched funding_locked_txid_sent_in_reestablish.

In a sequential-splice scenario (first splice promoted, second splice negotiated and confirmed locally, then reconnect), this would send splice_locked for the previously promoted splice's txid. If the peer has already promoted that splice and has a pending_splice for the second splice, their splice_locked handler would check negotiated_candidates for the old txid, not find it, and force-close the channel with "unknown splice funding txid".

Consider adding self.pending_splice.is_none() to the guard to match the comment's intent—this branch should only handle the case where pending_splice was cleared due to promotion:

Suggested change

	}).or_else(|| {
	// If a splice confirms after we've sent `channel_reestablish` but before we've
	// received theirs, we may promote the splice while disconnected and clear
	// `pending_splice`. We still need to send `splice_locked` after reestablishing
	// unless the promoted txid was already included in our `channel_reestablish`.
	let current_funding_txid = self.funding.get_funding_txid()?;
	(self.funding.channel_transaction_parameters.splice_parent_funding_txid.is_some()
	&& Some(current_funding_txid) != funding_locked_txid_sent_in_reestablish)
	.then(|| msgs::SpliceLocked {
	channel_id: self.context.channel_id,
	splice_txid: current_funding_txid,
	})
	});
	}).or_else(|| {
	// If a splice confirms after we've sent `channel_reestablish` but before we've
	// received theirs, we may promote the splice while disconnected and clear
	// `pending_splice`. We still need to send `splice_locked` after reestablishing
	// unless the promoted txid was already included in our `channel_reestablish`.
	let current_funding_txid = self.funding.get_funding_txid()?;
	(self.pending_splice.is_none()
	&& self.funding.channel_transaction_parameters.splice_parent_funding_txid.is_some()
	&& Some(current_funding_txid) != funding_locked_txid_sent_in_reestablish)
	.then(|| msgs::SpliceLocked {
	channel_id: self.context.channel_id,
	splice_txid: current_funding_txid,
	})

[ldk-claude-review-bot]

Review Summary

One issue found:

• lightning/src/ln/channel.rs:10790-10802 — The or_else fallback for sending splice_locked for a promoted splice can also fire when self.pending_splice is Some (but sent_funding_txid was filtered out). In a sequential-splice scenario this would send splice_locked for an already-promoted splice's txid, which the peer could reject with a force-close. Adding self.pending_splice.is_none() to the guard would prevent this.

The remaining changes look correct:

• Clearing monitor_pending_revoke_and_ack and monitor_pending_commitment_signed during reestablish when the peer's commitment numbers prove the messages were already delivered is sound. The reestablish proof is authoritative over stale ChannelManager state.
• Moving splice_locked (and tx_signatures/tx_abort) before commitment updates in handle_channel_resumption is the right ordering — the peer needs to know about the splice promotion before processing commitment updates for the post-splice channel.
• The two new tests cover the intended scenarios well.

[jkczyz]

I don't understand the "we may promote the splice while disconnected and clear" part. Isn't the fact that we've sent channel_reestablish indicate we are connected? Should this have said, "we may have promoted the splice while disconnected and have cleared"?

Commit message is similarly confusing to me.