TxAbort 将本地资金失败原因隐藏为通用的"资金取消"信息

问题 当自动接受方配置了默认共同出资金额 99 CKB，但钱包容量不足时： 接受方的本地日志显示了完整的原因：无法构建 CKB 交易：余额容量错误：容量不足：需要更多容量，值为 99.0；通道开启者只收到 TxAbort("funding aborted")；通道记录也只保留了通用的出资失败，因此无论远程对端还是 RPC 结果都无法表明真正的原因是接受方的余额不足。 在 08:29:06 / 08:36:53 / 08:39:04 / 08:41:20 UTC 同一 fnn 进程上以确定性方式重现了此问题；在水龙头资金到达后，同一代码路径立即成功了，时间为 08:49 UTC — 因此排除了传输问题或不稳定性。 根本原因 network.rs 的 schedule_funding_retry 可以访问和记录具体的 FundingError；一旦资金通道失败并做出了中止决定，它只调用 abort_funding(channel_id)，丢弃了错误内容；abort_funding 总是发送 StopReason::FundingFailed；在 channel.rs 中，当 funding_abort_detail 缺失时，它会回退到"资金中止"；代码已经有了 AbortFundingWithDetail(String)，以及像 TxUpdate 验证这样的路径已经使用了它 — 因此可以不再添加新的机制来统一它们。 还值得审查其他 abort_funding 调用位置；例如，当前链上资金交易失败可能以同样的方式丢失其具体原因。 建议的修复 让 abort_funding 接受一个结构化的原因，或者添加 abort_funding_with_detail，将最终的 FundingError 转换为 AbortFundingWithDetail；对端面的消息应该是一个稳定的、经过清理的、长度受限的错误，例如本地资金失败：自动出资的容量不足（99 CKB），而本地日志则保留了完整的错误链；最好统一 TxAbort 发送路径，这样签名路径不会发送详细的 TxAbort，而其他路径则回退到通用的路径；可选地在自动接受之前添加余额预检或警告，但仅作为用户界面提示（余额和单元状态可能同时发生变化）；最终决定仍然必须基于实际交易构建结果。 接受标准 当自动接受方余额不足时，开启方的 TxAbort/失败详情清楚地区分了容量不足而不是通用的资金中止；现有的临时 FundingError 重试策略没有变化；最终原因仅在耗尽重试后中止时才附加；在资金充足时，通道打开、重连和支付流程不会出现回退；对端可见的信息不得泄露内部路径、RPC 端点或敏感的交易构建细节，并且必须受到长度限制；测试涵盖了 fund、sign 和其他 abort_funding 调用位置。 建议的优先级：P2 / 可诊断性 — 基金安全性和协议正确性未受影响，但当前错误显著增加了跨节点调试成本。