fix: prevent false on-chain send success

[ovitrif]

Refs #717

Description

• Report an on-chain send as successful only after the configured backend accepts its transaction.
• Keep failed and timed-out broadcasts pending under their durable LDK transaction lineage instead of offering a fresh spend.
• Serialize the pending-broadcast check and transaction creation on the LDK queue.
• Reconcile pending, accepted, and abandoned outcomes across sheet reopen, app restart, and RBF lineage changes.
• Persist Paykit proof completion or abandonment before acknowledging the handled outcome.
• Preserve rejected and not-dispatched outcomes as conclusive failures that remain retryable.

Out of Scope

• LDK Node: broadcast recovery implementation and package publication are tracked in fix: wait for broadcast result ldk-node#113.

Dependency

• Requires the published Swift rc.67 package from fix: wait for broadcast result ldk-node#113, including the durable BroadcastOutcome lookup and acknowledgement APIs.
• The project remains pinned to published rc.66 while the final rc.67 package is unpublished. Update the dependency and complete consumer build/tests when it is available.

Design

N/A — no design available.

Preview

Earlier accepted and deterministic rejection captures:

717-current-artifact-accepted.mp4

717-current-artifact-rejected.mp4

Current-head pending/outcome media was not recorded.

QA Notes

Journeys

• new broadcast-accepted.xml: accepted on-chain send.
• new broadcast-rejected.xml: deterministic rejected on-chain send.

Manual Tests

• 1. Send → backend timeout or operational failure: Payment Pending appears without Bitcoin Sent or a sent activity.
• 2. Payment Pending → close → reopen Send → confirm another on-chain payment: the existing transaction reopens in Payment Pending without creating a fresh spend.
• 3. Payment Pending → Retry: the exact persisted transaction is rebroadcast and Bitcoin Sent appears only after accepted evidence.
• 4. Payment Pending → RBF replacement → Retry: the active replacement is rebroadcast and Paykit proof association follows its lineage.
• 5. Send → deterministic rejected or not-dispatched result: Transaction Failed appears and a fresh retry remains available.
• 6. Paykit on-chain request → acceptance-unknown result → app restart → accepted replacement: the proof submits the authoritative replacement transaction ID once.
• 7. Payment Pending → abandoned outcome: Transaction Failed appears, no payment proof is submitted, and a fresh send remains available.

Automated Checks

• ran local verification after rebasing onto master f4d4dbe at head 90ba10c: translation validation, SwiftFormat lint and Swift syntax parsing for all nine changed Swift files, JavaScript syntax, both journey XML parses, and diff whitespace checks passed.
• ran standard Bitkit test-target compilation with Xcode 26.6 / iOS 26.5: blocked because published LDK rc.66 lacks BroadcastOutcome; unit tests did not execute.
• updated OnchainSendResultTests.swift, PaykitPaymentProofServiceTests.swift, and QuickPayPaymentCoordinatorTests.swift: cover serialized query-and-create, callback ordering, query failures, exact rebroadcast, pending/accepted/abandoned outcomes, replacement lineage, conclusive errors, Paykit deferral, and acknowledgement ordering.
• Earlier head 6454ee3 passed 7/7 OnchainSendResultTests against an unpublished source-equivalent artifact; that result does not validate the current reconciliation changes.
• Marketplace regtest previously confirmed the accepted 1,000 sat transaction 158bdd1c2b81413b451f16b3331d261086daa73d03869e7a72099e5e83c6b in block 00941d326f26ccedfec7305849c0c176442a9e3c1509dc2c0b9a934768d5fc5b.
• The deterministic rejected path previously showed Transaction Failed for RPC -26 non-final without reaching success.