feat(sdk): add the DashPay tab to KotlinExampleApp (migration K3)

[shumkov]

Issue being fixed or feature implemented

Milestone K3 — the final milestone of the DashPay Swift→Kotlin migration (docs/dashpay/KOTLIN_MIGRATION_SPEC.md §K3): the first-class DashPay tab with all 10 Views/DashPay/ screens, the navigation restructure, and the parity bookkeeping. Stacked on #4027 (K2), which stacks on #4025 (K1). With this PR the migration's three milestones are complete.

What was done?

Navigation restructure (mirrors Swift ContentView.swift): RootTab is now SYNC / WALLETS / IDENTITIES / DASHPAY / SETTINGS — the Contracts tab is demoted into Settings → Platform (kept fully functional), and the stale FriendsScreen (port of a Swift view #3841 deleted) is retired with its entry points repointed at the DashPay tab.

The DashPay tab — all 10 views ported (one Compose file per Swift file, Swift sources cited in KDoc, iOS accessibility identifiers reused verbatim as testTags):

• DashPayTabScreen (hub: identity picker, pull-to-refresh → dashPaySyncNow, per-account balances, the seedless-unlock banner over dashPayUnlockStatus with in-flight guard), ContactsScreen, ContactRequestsScreen (accept/ignore with Room-scoped optimistic overlays), AddContactScreen (debounced wallet-scoped DPNS search, raw-id entry, QR scan-to-send), ContactDetailScreen (cached contact profile, alias/note/hide via setContactInfo surfacing the DIP-15 ContactInfoPublishOutcome, payment history via the durable refresh→Room path, paymentChannelBroken gating), SendDashPayPaymentSheet (NonCancellable money path + dismissal blocked while sending + refresh-after-send durability invariant), DashPayProfileScreen (view/edit + DIP-15 auto-accept QR), IgnoredContactsScreen, HiddenContactsScreen, and DashPayContactMeta (shared meta store singleton + Coil avatar with initials fallback; incoming-request avatars deliberately never load remote images).
• Bridged the final two exports: platform_wallet_build_auto_accept_qr / platform_wallet_send_contact_request_from_qr (QR crypto stays entirely Rust-side).
• Lifecycle: the DashPay sweep starts/stops with the wallet-scoped services in AppContainer (the manager auto-unlocks + status-polls from loadPersistedWallets, per K2).
• New dependency: coil-compose (avatar loading) — the migration's only third-party addition.

Parity bookkeeping: full PARITY.md rewrite — new Views/DashPay/ section (one row per view), FriendsView marked retired, totals corrected (97 views), and every material deviation documented (hub uses nav-section rows instead of a segmented control; in-memory identity selection; optimistic-sent overlay dropped; alias/note editors are AlertDialogs; the dropped iOS-only testTags listed).

Code-reviewed by two independent lenses (Compose state/concurrency; Swift-parity + doctrine incl. the QR bridges): 1 must-fix (payment-sheet dispose-mid-send losing post-broadcast bookkeeping — a double-payment risk Swift doesn't have) and 5 should-fixes found and folded, including NativeCleaner GC backstops on the contact-request handle wrappers and the buildAutoAcceptQr signature parity fix.

How Has This Been Tested?

• Compose UI tests (DashPayTabUITest, androidTest): the network-free render-state flows from DashPayTabUITests.swift, adapted for the documented hub deviation. Compile-gated locally; executed by the CI emulator in this PR.
• Gates local-green across every commit: :app:compileDebugKotlin, :app:compileDebugAndroidTestKotlin, :sdk:compileDebugKotlin, :sdk:testDebugUnitTest, cargo check/clippy/fmt on the JNI crate.
• ⚠ Honest gaps: the review's concurrency fixes have no instrumented coverage (the UI test is render-only), and the spec's end-to-end send→accept→pay testnet UAT (QA_TESTCASES_SPEC.md flows, -Ptestnet=true) is device/testnet-bound and remains to be run against this stack — recommended before merging the K-series into feat(sdk): add Kotlin SDK and KotlinExampleApp (Android port of SwiftExampleApp) #3999's branch.

Breaking Changes

None externally. Within the unreleased KotlinExampleApp: the Contracts tab moved into Settings and the Friends route + friends.* testTags are gone (superseded by the DashPay tab). Within the unreleased Kotlin SDK: Dashpay.buildAutoAcceptQr takes a non-optional username: String (Swift parity).

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 5aff883d-cc96-4487-8af0-a6f73869e2cb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/kotlin-sdk-dashpay-k3

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

✅ Review complete (commit 78f3627)

[thepastaclaw]

Code Review

Source: reviewers = claude ffi-engineer opus; claude general opus; codex ffi-engineer gpt-5.5; codex general gpt-5.5; verifier = claude opus; specialists = ffi-engineer; policy gate = review_policy.enforce_backport_prereq_policy.

K3 lands the DashPay tab, 10 supporting Compose screens, and two QR JNI bridges. Two K3 defects need addressing: (1) the post-send refreshDashPayPayments runs on ContactDetailScreen's rememberCoroutineScope even though the send itself is NonCancellable, so the durability-refresh invariant the PR advertises can still be lost if composition leaves mid-send; (2) the DashPay tab's eligible filter omits Swift's !isLocal check and exposes pending-registration identities to real state-transition flows. Additionally: HiddenContactsScreen.unhide discards the ContactInfoPublishOutcome (DEFERRED/WATCH_ONLY paths regress silently), an unused alias/note/hidden accessor block on DashPayContactMetaStore, and a small misleading error message on the QR JNI. FFI/JNI boundary and Cleaner-backed handle destruction are clean.

🔴 2 blocking | 🟡 1 suggestion(s) | 💬 2 nitpick(s)

Additional Verified Findings

• [NITPICK] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPayContactMeta.kt:40-104: DashPayContactMetaStore setAlias / setNote / setHidden / isHidden / note are dead API
  setAlias, setNote, setHidden, isHidden, and the note(...) reader are defined on DashPayContactMetaStore but have no callers anywhere in KotlinExampleApp — grep confirms only alias(...) (used by ContactRequestsScreen for pending-incoming rows) and dpnsHint/setDpnsHint are load-bearing. Alias / note / hidden are now round-tripped through setContactInfo → Room (contactAlias, contactNote, contactHidden on the contact-request rows). Either delete the unused accessors or document the device-local dpnsHint vs Platform-synced alias/note/hidden divide so a future contributor doesn't reach for metaStore.setAlias in ContactDetail.

• [NITPICK] packages/rs-unified-sdk-jni/src/dashpay.rs:874-877: sendContactRequestFromQr throws "uri must not be null" for non-null URIs containing interior NUL bytes
  opt_jstring_to_cstring returns None for two distinct failure modes: env.get_string(...) failing, or CString::new(...) rejecting the string because it contains an interior NUL byte. The thrown message "uri must not be null" misdiagnoses the second case — the URI string was received; it just wasn't marshalable as a C string. A QR scanner's payload won't hit this, but a paste / test injection will surface a misleading error. Use e.g. "uri must not be null or contain embedded null bytes".

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/ContactDetailScreen.kt`:
- [BLOCKING] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/ContactDetailScreen.kt:352: Post-send payment refresh still runs on a cancellable Compose scope
  `SendDashPayPaymentSheet.send()` correctly wraps the broadcast + `onSent()` in `withContext(NonCancellable)`, with the comment explicitly stating that losing the durability refresh would "invite a double-send." But `onSent = { refreshPayments() }` calls `ContactDetailScreen.refreshPayments`, which does `scope.launch { m.refreshDashPayPayments(wid, idBytes) }` on the composable's `rememberCoroutineScope`. If ContactDetailScreen leaves composition while the send is in flight (system back after the sheet's confirmValueChange stops blocking, config change, process death handoff, or the `delay(1500); onClose()` tail window), the parent scope is cancelled — so the new `scope.launch` for the refresh is dead-on-arrival even though the caller thinks it's inside NonCancellable. The net result contradicts the stated invariant: the payment is broadcast but its Room upsert doesn't run through the durability path. Either run `refreshDashPayPayments` directly inside the sheet's NonCancellable block (before `onSent()` returns), or route it through a scope tied to the wallet manager / application, not the screen.

In `packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPayTabScreen.kt`:
- [BLOCKING] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/DashPayTabScreen.kt:102-106: Eligible-identity filter is missing the `!isLocal` gate (parity with Swift)
  Swift's `eligibleIdentities` (DashPayTabView.swift:95-100) requires `!identity.isLocal` before considering an identity DashPay-usable. The Kotlin filter only checks `walletId != null && walletsMap.containsKey(...)` and the underlying DAO (`observeWalletOwnedByNetwork`) does not filter isLocal either. `IdentityEntity.isLocal` defaults to `true`, so any wallet-created-but-unregistered identity (pending registration) makes it through and gets the full DashPay hub. That identity is not on Platform yet, so contact-request sends, profile creation, and setContactInfo will all fail against real errors — the correct UX is the "No identities yet" empty state until registration completes. Add the `!isLocal` filter here.

In `packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/HiddenContactsScreen.kt`:
- [SUGGESTION] packages/kotlin-sdk/KotlinExampleApp/app/src/main/java/org/dashfoundation/example/ui/dashpay/HiddenContactsScreen.kt:107-132: unhide() discards ContactInfoPublishOutcome — DEFERRED / SKIPPED_WATCH_ONLY unhides regress silently
  `unhide` calls `w.dashpay.setContactInfo(..., displayHidden = false, ...)` and unconditionally adds the contact hex to `removedOverlayIds`, ignoring the returned `ContactInfoPublishOutcome`. `ContactDetailScreen.saveContactInfo` handles the same outcome carefully and surfaces `DEFERRED_UNTIL_TWO_CONTACTS` / `SKIPPED_WATCH_ONLY` via `publishNotice`. Here, when the outcome is DEFERRED or SKIPPED_WATCH_ONLY the Platform-side `contactInfo.displayHidden` is not flipped, so a subsequent Platform sync sweep can restore `contactHidden = true` on the Room row. `removedOverlayIds` is per-composition, so after navigate-away-and-back the contact reappears in the Hidden list without any explanation. Watch-only identities in particular cannot unhide from this screen and the failure mode is completely silent. Mirror ContactDetail: capture the outcome and render a row-level notice / inline error for non-PUBLISHED outcomes.

[thepastaclaw]

🔴 Blocking: Post-send payment refresh still runs on a cancellable Compose scope

SendDashPayPaymentSheet.send() correctly wraps the broadcast + onSent() in withContext(NonCancellable), with the comment explicitly stating that losing the durability refresh would "invite a double-send." But onSent = { refreshPayments() } calls ContactDetailScreen.refreshPayments, which does scope.launch { m.refreshDashPayPayments(wid, idBytes) } on the composable's rememberCoroutineScope. If ContactDetailScreen leaves composition while the send is in flight (system back after the sheet's confirmValueChange stops blocking, config change, process death handoff, or the delay(1500); onClose() tail window), the parent scope is cancelled — so the new scope.launch for the refresh is dead-on-arrival even though the caller thinks it's inside NonCancellable. The net result contradicts the stated invariant: the payment is broadcast but its Room upsert doesn't run through the durability path. Either run refreshDashPayPayments directly inside the sheet's NonCancellable block (before onSent() returns), or route it through a scope tied to the wallet manager / application, not the screen.

_{source: ['codex']}

[thepastaclaw]

🔴 Blocking: Eligible-identity filter is missing the !isLocal gate (parity with Swift)

Swift's eligibleIdentities (DashPayTabView.swift:95-100) requires !identity.isLocal before considering an identity DashPay-usable. The Kotlin filter only checks walletId != null && walletsMap.containsKey(...) and the underlying DAO (observeWalletOwnedByNetwork) does not filter isLocal either. IdentityEntity.isLocal defaults to true, so any wallet-created-but-unregistered identity (pending registration) makes it through and gets the full DashPay hub. That identity is not on Platform yet, so contact-request sends, profile creation, and setContactInfo will all fail against real errors — the correct UX is the "No identities yet" empty state until registration completes. Add the !isLocal filter here.

Suggested change

	val eligible = remember(allWalletOwned, walletsMap) {
	allWalletOwned
	.filter { it.walletId != null && walletsMap.containsKey(it.walletId!!.toHex()) }
	.sortedBy { it.createdAt.time }
	}
	val eligible = remember(allWalletOwned, walletsMap) {
	allWalletOwned
	.filter { !it.isLocal && it.walletId != null && walletsMap.containsKey(it.walletId!!.toHex()) }
	.sortedBy { it.createdAt.time }
	}

_{source: ['codex']}

[thepastaclaw]

🟡 Suggestion: unhide() discards ContactInfoPublishOutcome — DEFERRED / SKIPPED_WATCH_ONLY unhides regress silently

unhide calls w.dashpay.setContactInfo(..., displayHidden = false, ...) and unconditionally adds the contact hex to removedOverlayIds, ignoring the returned ContactInfoPublishOutcome. ContactDetailScreen.saveContactInfo handles the same outcome carefully and surfaces DEFERRED_UNTIL_TWO_CONTACTS / SKIPPED_WATCH_ONLY via publishNotice. Here, when the outcome is DEFERRED or SKIPPED_WATCH_ONLY the Platform-side contactInfo.displayHidden is not flipped, so a subsequent Platform sync sweep can restore contactHidden = true on the Room row. removedOverlayIds is per-composition, so after navigate-away-and-back the contact reappears in the Hidden list without any explanation. Watch-only identities in particular cannot unhide from this screen and the failure mode is completely silent. Mirror ContactDetail: capture the outcome and render a row-level notice / inline error for non-PUBLISHED outcomes.

_{source: ['claude']}

[thepastaclaw]

💬 Nitpick: DashPayContactMetaStore setAlias / setNote / setHidden / isHidden / note are dead API

setAlias, setNote, setHidden, isHidden, and the note(...) reader are defined on DashPayContactMetaStore but have no callers anywhere in KotlinExampleApp — grep confirms only alias(...) (used by ContactRequestsScreen for pending-incoming rows) and dpnsHint/setDpnsHint are load-bearing. Alias / note / hidden are now round-tripped through setContactInfo → Room (contactAlias, contactNote, contactHidden on the contact-request rows). Either delete the unused accessors or document the device-local dpnsHint vs Platform-synced alias/note/hidden divide so a future contributor doesn't reach for metaStore.setAlias in ContactDetail.

_{source: ['claude']}

[thepastaclaw]

💬 Nitpick: sendContactRequestFromQr throws "uri must not be null" for non-null URIs containing interior NUL bytes

opt_jstring_to_cstring returns None for two distinct failure modes: env.get_string(...) failing, or CString::new(...) rejecting the string because it contains an interior NUL byte. The thrown message "uri must not be null" misdiagnoses the second case — the URI string was received; it just wasn't marshalable as a C string. A QR scanner's payload won't hit this, but a paste / test injection will surface a misleading error. Use e.g. "uri must not be null or contain embedded null bytes".

_{source: ['claude']}