Avoid assertion on delayed splice tx_signatures

[Supremesv715]

fix #4729 Defers delayed splice tx_signatures during unrelated monitor updates

[ldk-reviews-bot]

👋 Thanks for assigning @wpaulino 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]

No issues found.

The production change in lightning/src/ln/channel.rs:9690 is a correct, minimal fix for #4729. Replacing the debug_assert!(self.context.monitor_pending_tx_signatures) with an unconditional self.context.monitor_pending_tx_signatures = true:

• Is idempotent in the original splice-initial-commitment case (the flag is already set at line 8584), so it doesn't change that path's behavior.
• Correctly handles the previously-asserting case where an unrelated monitor update (e.g. an HTLC fulfillment) is pending when delayed splice tx_signatures arrive. The flag now ensures monitor_updating_restored (line 9914) releases the deferred tx_signatures once the monitor update completes.
• The deferral remains safe because received_tx_signatures (line 9670) records counterparty/holder signatures and marks the session before the early return, and the restore path is guarded by signer_pending_funding / holder_tx_signatures() availability, so nothing is released prematurely. This is consistent with the signer_unblocked path (line 10204), which already skips release while is_awaiting_monitor_update().

The added regression test exercises the exact scenario from the issue (deferred tx_signatures while an HTLC-fulfill monitor update is in progress). No bugs, security issues, or logic errors found in the diff.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.