Return the interactive-tx send error instead of hanging splice_update

[vincenzopalazzo]

Summary

• splice_update hung after the peer answered the first tx_add_input with tx_complete and then nothing else went out. Fixes splice_update hangs and never returns, even after disconnecting peer #9599.
• Reproduced on current master (019a5e190). The turn loop in process_interactivetx_updates discarded the error from send_next. The shared funding input is built by channeld, so that first turn succeeds. The user's input needs the previous transaction in the PSBT. utxoupdatepsbt only fills witness_utxo, so the next send fails, nothing is written, and channeld blocked in peer_read.
• Return that error. splice_update now fails with interactivetx ADD_INPUT PSBT needs the previous transaction set instead of staying pending. No disconnect is required.
• A peer tx_complete is still just one turn. We do not finalize the splice there.

Test plan

• test_splice_update_missing_prevtx on current master: strip PSBT_IN_NON_WITNESS_UTXO from the user's input and splice_update returns RpcError matching previous transaction
• test_splice still completes a normal splice
• CI

[ksedgwic]

Concept ACK: the one-line change is the right fix for #9599.
channeld builds the shared input, so the first turn goes out and the peer answers tx_complete; on the second turn the user's input fails the in->input.utxo check in send_next. With the return value dropped nothing was written and the loop went back to peer_read.

Two suggestions before merge:

1. Exit path: suggest rejecting the PSBT in lightningd at splice_init and splice_update instead of exiting through a warning.
   Today the error reaches splice_initiator_user_update, which calls peer_failed_warn: channeld exits, the peer gets a warning and the connection is dropped. The RPC returns only because the warning is the disconnect case in channel_control_errmsg. A check in json_splice_init and json_splice_update (every input other than the channel's funding outpoint needs psbt->inputs[i].utxo, else SPLICE_INPUT_ERROR) fails the RPC before anything reaches channeld: nothing goes on the wire, the peer is still waiting, and splice_update can be retried with a corrected PSBT or the splice aborted. The interactivetx change stays as the backstop.

2. Test: suggest asserting the channel is usable after the error, and optionally building the PSBT the way the report did.
   With the current exit channeld dies, so the test could wait for the reconnect and then complete a normal splice. bitcoind.rpc.createpsbt on a listfunds output followed by utxoupdatepsbt gives the witness_utxo-only shape from the report directly, without the PSBT walker.

Separate from this PR: the forced-disconnect half of #9599 is still open, because the pending splice command is only failed on the warning path.
channel_control_errmsg fails it only when disconnect is set, and force_peer_disconnect goes through channel_set_owner(NULL) to subd_release_channel, which clears sd->channel before freeing, so no errcb runs. Once channeld is gone the splice state is gone with it, so the pending command can be failed on every channeld exit.

CI did not run on d05e7fe; both runs were cancelled at start.