channeld: fix channel_ready retransmission after splice via funding_tx_index

[nGoline]

Problem

On reconnect, channeld decides whether to retransmit channel_ready based on whether the peer's channel_reestablish references a splice (is_splice_active). It computed that by comparing the peer's my_current_funding_locked txid against peer->channel->funding.txid.

That comparison is wrong once a splice locks: channel_update_funding() overwrites funding.txid with the splice txid, so afterwards both sides agree on the same txid, the check falls through, and channel_ready is incorrectly retransmitted on reconnect, which can disrupt channels.

This is the problem @ddustin raised reviewing #9079 (comparing against the txid is incorrect, and we should track metadata on the inflight instead), suggesting a funding_tx_index, matching what eclair does.

Fix

Give every funding tx a stable funding_tx_index: 0 for the original funding (including RBF attempts), incrementing by 1 per splice. It is:

• carried on the channeld inflight and on the channel,
• threaded through the channeld_init and channeld_add_inflight wire,
• assigned on splice creation (parent + 1) and copied onto the channel funding when a splice locks,
• persisted in channel_funding_inflights and channels (two migrations, DEFAULT 0, so existing channels are unaffected).

The reestablish check now resolves the my_current_funding_locked txid to its funding_tx_index (current funding or a pending inflight) and treats > 0 as a splice.

Commits (bisectable)

1. splice: add tests for funding_tx_index tracking, regression tests (xfail).
2. splice: track funding_tx_index on inflights and channel funding, the plumbing.
3. channeld: detect splice on reestablish via funding_tx_index, not txid, the fix.

Tests

• test_splice_reconnect_after_lock_no_channel_ready: splice, restart, reestablish; asserts the index persists and channel_ready is not retransmitted. It fails on commit 2 (old txid compare) and passes on commit 3, so it genuinely guards the fix.
• test_splice_funding_tx_index_increments: two sequential splices reach index 2.
• test_splice_inflight_funding_tx_index: a pending splice inflight carries index 1 and survives a restart.
• Existing test_reconnect_no_update confirms non-splice channels still retransmit channel_ready.

Risk and plan

The behavioural change is a single line in the reestablish check. The plan is to get the funding_tx_index semantics reviewed properly, and if we don't converge before the v26.09 freeze, revert that one line with a FIXME and keep the plumbing for the follow-up. So this carries low risk.

@ddustin, this implements the funding_tx_index approach you suggested; would appreciate your review of the assignment semantics and whether it matches what you and tbast had in mind.

[ddustin]

This is great! 👏 Mostly style notes with only one major concern:

test_splice_reconnect_after_lock_no_channel_ready may not actually be testing for the lack of channel_ready because of the unneeded billboard: Channel ready for use. check.

[ddustin]

It looks like you meant to query this from the RPC instead of db? Doesn't seem critical since test_splice_reconnect_after_lock_no_channel_ready should cover this already.

[nGoline]

This was intentional. The inflight funding_tx_index isn't exposed over any RPC since it's internal channeld/inflight state, so the test reads channel_funding_inflights directly to prove it persists and reloads across restart.

[nGoline]

@ddustin this is the only thing I haven't changed, as it was intentional. Are you good to merge?

[nGoline]

@ddustin comments addressed. Just waiting for your review.