fix: prevent false success for rejected on-chain sends

[ovitrif]

Parent: #712
Source: Pubky marketplace Bitkit team brief
Counterpart: synonymdev/bitkit-android#1211

Scope

• Reproduce the stale Electrum-tip/non-final transaction case from the brief.
• Determine whether ownership lies in Bitkit, LDK Node, or the Electrum integration, and link any upstream issue.
• Make the send result distinguish accepted broadcast from local submission when the backend rejects or drops the transaction.

Acceptance criteria

• The reproduced non-final transaction is not shown as Bitcoin Sent.
• A clean-wallet accepted transaction still completes normally.
• Regression coverage records the expected signal.

Why this is required for 2.6.0

Required for Shop support in Bitkit 2.6.0: buyers must be able to tell whether an on-chain payment was accepted and recover an uncertain checkout without paying twice.

• Prevent false success: Bitkit must not show “sent” or deliver payment proof when the backend rejected the transaction or acceptance is still unknown; the Shop order may remain unpaid.
• Prevent accidental double payment: reopening or retrying an uncertain checkout must retain the original payment instead of starting a separate payment.
• Preserve the merchant amount on retry: use only the original inputs and recipient amount; a Max payment without enough fee headroom must fail safely rather than reduce what the merchant receives.
• Resolve stale Pending state: once the exact original payment succeeds and its local follow-up is saved, the app must reflect that result.
• Preserve protection after wallet restore: restoring a backup must retain the unresolved payment guard so it cannot silently authorize another send.

These are release acceptance requirements. Final Shop checkout still needs validation against the Paykit/server versions selected for 2.6.0.

[ovitrif]

Root cause is upstream in synonymdev/ldk-node#112.

Both iOS and Android pin LDK Node 0.7.0-rc.63. Its on-chain send API returns a Txid after enqueueing the transaction, before Electrum/Esplora/bitcoind processes the broadcast. Backend rejection cannot reach either mobile caller. The Electrum path additionally logs a successfully joined task as a successful broadcast without inspecting the nested transaction_broadcast result, which explains the reported “successful Electrum broadcast” for the rejected non-final transaction.

The upstream issue includes the stale-tip reproduction, exact pinned/current revisions, mobile call-site impact, and required accepted-versus-submitted result contract.

[ovitrif]

Refs:

• fix: prevent false on-chain send success #844
• fix: prevent false on-chain send success bitkit-android#1384
• fix: report on-chain broadcast outcomes ldk-node#119

The current fix separates backend acceptance from transaction creation. Normal sends, Max, transfers and Shop payments use the explicit node outcome; rejected or unknown results keep the original attempt protected rather than authorizing another payment.

The app saves a bounded attempt guard before dispatch. Accepted results can finish local storage/activity/proof work without another send; independent positive reconciliation must identify the exact original transaction. Shop proof and backup state also carries explicit acceptance evidence, so a txid-shaped value alone cannot mark a request paid.

Hardware Shop callbacks require a fresh observation of the exact outgoing transaction in the original persisted hardware wallet. The original identity/request/wallet context is retained; missing observation remains Pending and cannot mint a proof or start a replacement payment.

This approach intentionally has no transaction journal, automatic rebroadcast, RBF recovery, abandonment or reorg redesign. A lost result can leave the original attempt blocked indefinitely. Backend acknowledgement does not guarantee confirmation, and the bounded local guard does not provide exactly-once guarantees across devices or restored backups.

[ovitrif]

The implemented acceptance change is in #844. Review follow-up preserves a stricter boundary: only a proven failure before native dispatch can release its attempt; accepted payments resume original local work without another broadcast.

A refused result, as well as an unknown/lost result, can leave on-chain sends blocked indefinitely if the transaction never becomes positively observed. The pinned transport can lose earlier delivery history during retries, so a refusal response or negative sync is not a safe no-payment certificate. Refusal release or input-pinning recovery remains an open review discussion and was not implemented.

Pre-upgrade software proofs from opted-in released builds can also remain undelivered: a queued-era transaction ID lacks positive acceptance and original-wallet provenance. This PR does not promote a local Sent row into acceptance or guess the current wallet. The limitation and proposed migration remain documented in the open review thread.

[ovitrif]

@jvsena42 accepted the documented legacy software-proof limitation as non-blocking: released builds can contain opt-in records, but Paykit default-on has not shipped. Migration remains excluded from this PR; unverified queued-era transaction IDs are not promoted or delivered. The refusal-release discussion remains open. No source or dependency change accompanies this scope clarification.

[ovitrif]

The implementation now provides an explicit retry of the original on-chain payment rather than indefinite refusal/unknown lockout. It requires the signed transaction receipt to be persisted before broadcast; each successor preserves the original recipient amount and exact inputs, and all candidate transaction IDs remain guarded across restart. Fresh payer/request/order authorization is required, and an accepted or observed original candidate remains the winner.

This depends on the prepared-send API in synonymdev/ldk-node#122 and its matching rc69 prerelease. Missing original provenance or insufficient fee headroom fails safely; backend absence never unlocks a separate payment. The app PR remains draft for Bitkit 2.6.0 pending funded Shop/backend-fault/hardware checks and current-head review.