f - Preserve funding details when a splice candidate is replaced

The TxReplaced wallet event rebuilt the payment record from scratch,
dropping its funding details. When a wallet sync fell between a splice
broadcast and its RBF, the replacement of the original candidate cleared
those details, so the payment no longer graduated to Succeeded on
ChannelReady. Funding records are managed by the classify path and the
Lightning lifecycle handlers, so leave them untouched on replacement.

Co-Authored-By: Claude <noreply@anthropic.com>

Author: jkczyz

src/wallet/mod.rs

@@ -410,6 +410,18 @@ impl Wallet {
 						continue;
 					};
 
+					// Funding records (channel opens and splices) track their active candidate and
+					// status through `classify_*` and the Lightning lifecycle handlers. A replaced
+					// candidate is expected during splice RBF and must not reset the record or drop
+					// its funding details, so leave such records untouched here.
+					if self
+						.pending_payment_store
+						.get(&payment_id)
+						.map_or(false, |p| p.funding_details.is_some())
+					{
+						continue;
+					}
+
 					// Collect all conflict txids
 					let mut conflict_txids: Vec<Txid> =
 						conflicts.iter().map(|(_, conflict_txid)| *conflict_txid).collect();

tests/integration_tests_rust.rs

@@ -1218,6 +1218,24 @@ async fn rbf_splice_channel() {
 	let original_txo = expect_splice_negotiated_event!(node_a, node_b.node_id());
 	expect_splice_negotiated_event!(node_b, node_a.node_id());
 
+	// Sync so the original splice candidate is recorded as a canonical wallet transaction before
+	// the RBF below replaces it. This makes the post-RBF sync observe the original candidate being
+	// replaced (a `WalletEvent::TxReplaced`), which must not drop the payment's funding details.
+	//
+	// This is a best-effort regression guard rather than a deterministic one: with the
+	// funding-details-preservation fix in place the splice still graduates correctly, but without
+	// it the resulting inconsistency only surfaces intermittently (via a timing-dependent
+	// `debug_assert` in the chain-tip handler), so a reverted fix is caught probabilistically.
+	//
+	// TODO: Make this deterministic. If funding payments carried a durable classification in the
+	// main payment store (e.g. a `tx_type` on `PaymentKind::Onchain`, as in
+	// lightningdevkit/ldk-node#791), a dropped funding-details record would be a detectable
+	// contradiction on `ChannelReady` rather than a timing-dependent assert, letting this test
+	// fail reliably whenever the fix is reverted.
+	wait_for_tx(&electrsd.client, original_txo.txid).await;
+	node_a.sync_wallets().unwrap();
+	node_b.sync_wallets().unwrap();
+
 	// splice_in should fail when there's a pending splice (RBF guard)
 	assert_eq!(
 		node_b.splice_in(&user_channel_id_b, node_a.node_id(), 1_000_000),