Contact Detail loses pending payment after font-scale change #1617

What happened?

During device review of #1564, Contact Detail → Pay lost the pending payment when a font-scale change recreated the activity: the sheet disappeared, the amount screen did not open, and no error appeared.

John reproduced this twice on Pixel_9 at commit afcf6ff4ec512020e10934e7b346df3ca004e1ee. Original report and timestamps. This report is based on his device runs; the follow-up has not been independently reproduced yet.

Expected behavior

Keep a pending contact payment across activity recreation, then open it exactly once when the screen resumes. Cancellation, failure and retry must remain safe, including wallet/identity changes and duplicate-payment protection.

Steps to reproduce

1. Open a contact with payment methods.
2. Choose Pay, then confirm Pay in the sheet.
3. Change Android's font scale while payment details are resolving.
4. Return to Bitkit and check whether the payment opens or an explicit error appears.

Investigation

Source inspection confirms a cancellation path before the handoff: ContactDetailScreen calls dismissRequestOrPaySheet() from DisposableEffect.onDispose. When isPayLoading is true, that calls cancelPendingPayment(), cancelling payJob and paymentScanJob, then clears the loading and sheet state. A font-scale activity recreation can therefore cancel resolution even though its ViewModel survives. This is the mechanism identified in the follow-up review; no additional device reproduction has been performed here.

Both Contact Detail files are byte-identical at PR head afcf6ff4, its base 99497260, and current master ae800aef. The follow-up should distinguish screen recreation from an explicit dismissal or leaving the flow, preserving cancellation for the latter.

Also test the separate result-delivery boundary: Contact Detail sends OpenPayment through a non-replaying MutableSharedFlow, so a result produced without a collector may be lost. The Send → Contact path retains its pending result and passed the same perturbation in #1564. Do not assume that replacing the flow alone fixes the disposal cancellation.

Rotation alone did not reproduce it in the reviewer's configuration because it did not recreate that activity. Check cancellation, failed resolution, retry and return navigation as well as successful recreation. Compare iOS if its Contact Detail flow has an equivalent lifecycle gap.

Tracked separately from #1564 because that PR fixes the Send → Contact picker, not Contact Detail.