[ben-kaufman]

This PR lets automatic proof-triggered payment-request display updates yield to payment review and submission while retaining a fresh read on the next existing refresh opportunity.

Stacked on #1626. Native runtime validation is pending; no measured latency improvement is claimed.

Validation: Kotlin compile, all 4,424 unit tests, Detekt/format and Android Lint passed. Native runtime validation remains pending.

Description

• Give only the automatic proof observer's display reload Background admission while keeping its forced-freshness bookkeeping.
• Preserve warm request rows when admission defers and recover through the existing poll or Home/resume refresh; admitted reconciliation and explicit recovery keep Ordered admission.

Out of Scope

• Payment/recovery authority and SDK scheduling: no new retry scheduler, immediate-idle retry, or preemption of an already admitted operation.

Design

N/A — no UI changes.

Preview

N/A — no visual changes.

QA Notes

Journeys

N/A — not drivable; see Manual Tests.

Manual Tests

• regression: pause automatic proof reconciliation immediately before its display reload → begin payment review, then release reconciliation → warm request rows remain and the display reload yields; cancel review and resume Home → current request state appears — precise proof-reconciliation/admission fault injection not in Capabilities.

Automated Checks

• updated PaykitPaymentRequestRepoTest.kt — forced Background reads preserve warm state after deferral, later load current proof/request versions, and reject stale identity; explicit Ordered recovery remains available.
• updated AppViewModelSendFlowTest.kt — an admitted reconciliation finishes during a new payment, its display read defers, and Home resume recovers without an immediate retry loop.
• ran the observer regression with Ordered admission temporarily restored — it failed at the priority boundary; the frozen source was restored before the passing full suite.

[ovi-reviewer]

Verdict: ✅ Approve

Findings: No actionable findings.

QA for ce4db93:

Two Pixel 7 Android 15 emulators with disposable Bitcoin-regtest wallets and staging Pubky. The recording shows the payer on the left and requester on the right, at 2× speed.

Test 1: proof display admission and foreground recovery ✅ The display read deferred during review, retained the warm request, and later discovered a new request.

A local debug event entered the automatic proof observer, and a gate paused it after the real reconciliation call, before its display reload. I opened the existing 1,000-sat confirmation and released the gate. The SDK trace confirmed Background admission returned OperationInProgress before native observation, with the pending row and history unchanged. The observer made no immediate retry.

The requester sent a second, 2,000-sat request while confirmation stayed open. After cancelling review and backgrounding/reopening the app, existing foreground polling loaded it. The recording ends with both unpaid requests visible. The hook supplied the event, pause and logs; SDK admission, responses and request records were real. No payment was authorized.

j1.2x.mp4

Held confirmation, the second request, background/reopen and both retained rows; admission and history retention were checked in the SDK/repository trace.

Test 2: pristine build and admission regressions ✅ The unmodified head built and the focused suites passed.

I ran assembleDevDebug and testDevDebugUnitTest for PaykitPaymentRequestRepoTest, AppViewModelSendFlowTest and PaykitSdkServiceTest. Gradle and JUnit results confirmed execution without failures or skips, including the new observer regression, forced Background checkpoint reload, warm-state retention, stale-identity rejection and explicit Ordered recovery. No device media applies.

Coverage: full 5bd39a8…ce4db93, all five changed files and reached callers. Concurrent checkpoint changes, identity invalidation and explicit recovery have source and automated coverage; the native case used an injected observer event. It does not establish payment settlement or a latency improvement.

Twin: synonymdev/bitkit-ios#1066 fix: defer passive proof display refreshes at 6153563 matches forced Background display admission, warm-state retention and existing-refresh recovery. Its observer also waits for review to end and retains a session-scoped refresh token. No iOS device case was run here.

---

Reviewed by gpt-6.1-sol-high via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest

[ovitrif]

utAck