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.

Dependency

• Blocks on synonymdev/ldk-node#113 at source head 7d359aee31282c5f9a1a8fe65b24b523cb5c101b, which adds the durable BroadcastOutcome lookup and acknowledgement contract, retains recovery state before dispatch, and preserves recovery across cleanup persistence failures.
• The public binding contract is unchanged from predecessor 6b60fe0df32362d6c6604393071110e94a2058b8; the earlier local archive from that predecessor has checksum 549f7a962f7b4262ef77b7e65abd6fe588be87801bee35da6295571c141f183b and does not include the subsequent internal recovery fixes.
• The project remains pinned to published rc.66 until the final rc.67 package artifact is 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

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

• Current head a67f441b includes live master at 1cf0a425 and the authoritative-outcome integration. It was not built, parsed, formatted, or test-run; published rc.66 lacks the required APIs.
• Unit coverage updated for serialized query-and-create, query failure, exact rebroadcast, pending/accepted/abandoned outcomes, replacement lineage, conclusive errors, Paykit deferral, and acknowledgement ordering.
• Earlier head 6a6b0c06 passed source parsing, diff whitespace inspection, focused SwiftFormat inspection, and the CI translation check; those results do not validate the current outcome integration.
• 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.