TxAbort hides local funding failure reason behind generic "funding aborted"

Problem When the auto-accepting side is configured with the default co-funding amount of 99 CKB but has insufficient wallet capacity:

The acceptor's local log shows the full reason: Failed to build CKB tx: balance capacity error: capacity not enough: need more capacity, value=99.0; The channel opener only receives TxAbort("funding aborted"); The channel record also only keeps the generic funding failure, so neither the remote peer nor RPC results can tell that the real cause was the acceptor's insufficient balance. Reproduced deterministically on the same fnn process at 08:29:06 / 08:36:53 / 08:39:04 / 08:41:20 UTC; after faucet funds arrived, the same code path succeeded immediately at 08:49 UTC — ruling out transport issues or flakiness.

Root cause network.rs's schedule_funding_retry has access to and logs the concrete FundingError; Once fund-channel fails and the decision is made to abort, it only calls abort_funding(channel_id), dropping the error content; abort_funding always sends StopReason::FundingFailed; In channel.rs, when funding_abort_detail is absent it falls back to "funding aborted"; The code already has AbortFundingWithDetail(String), and paths like TxUpdate verification already use it — so this can be unified without new machinery. Also worth auditing other abort_funding call sites; e.g. on-chain funding transaction failure may currently lose its concrete reason the same way.

Suggested fix Let abort_funding accept a structured reason, or add abort_funding_with_detail, mapping the final FundingError into AbortFundingWithDetail; The peer-facing message should be a stable, sanitized, length-capped error, e.g. local funding failed: insufficient capacity for auto contribution (99 CKB), while the local log keeps the full error chain; Preferably unify the TxAbort sending path, so the signing path doesn't send a detailed TxAbort while other paths fall back to the generic one; Optionally add a balance pre-check/warning before auto-accepting, but only as a UX hint (balance and cell state can change concurrently); the final decision must still be based on the actual transaction building result. Acceptance criteria When the auto-acceptor has insufficient balance, the opener's TxAbort/failure detail clearly distinguishes insufficient capacity instead of the generic funding aborted; The existing retry policy for temporary FundingErrors is unchanged; the final reason is only attached when aborting after retries are exhausted; No regression in channel open, reconnection, and payment flows when funds are sufficient; Peer-visible information must not leak internal paths, RPC endpoints, or sensitive transaction construction details, and must be length-capped; Tests cover fund, sign, and other abort_funding call sites. Suggested priority: P2 / diagnosability — fund safety and protocol correctness are unaffected, but the current error significantly increases cross-node debugging cost.