feat(platform-wallet): token-minting finalize from a funding path (spendable DashPay receival accounts)

[bfoss765]

What this does

Bridges two flows that were previously disconnected in platform-wallet:

• build_signed_payment's single-account-by-derivation-path selection (feat(kotlin-sdk): single-account build_signed_payment send API (funding_path) #4247) — the only build path that can reach a DashpayReceivingFunds account; and
• the reservation/broadcast flow (feat(kotlin-sdk): split build/broadcast with reservation release for BIP70-style deferred submission #4185) — token → broadcastSigned / releaseReservation.

New finalize_signed_payment_from_funding_path returns a FinalizedCorePayment (signed tx, fee, change, the resolved FundingAccountRef, and the reservation token). The key correctness property: the reservation is recorded against the resolved account, never a BIP44 default, so release/broadcast bookkeeping lands in the same ledger the build reserved into. FundingAccountRef::Path makes non-standard accounts (DashPay receival) nameable to the release machinery, which previously could only address StandardAccountTypes.

Surface:

• wallet/core/transaction.rs — FundingAccountRef enum + release_reservation_for
• wallet/core/send.rs — finalize_signed_payment_from_funding_path, FinalizedCorePayment, abandon_payment
• wallet/signed_payment_registry.rs — register_funded_by
• FFI core_wallet_build_signed_payment_with_token
• JNI coreWalletBuildSignedPaymentWithToken
• Kotlin ManagedPlatformWallet.buildSignedPaymentWithToken(recipients, coreSignerHandle, feePerKb, fundingPath), returning the existing SignedCoreTransaction (now carrying changeDuffs)

Guardrails preserved and covered by tests: single-account funding only (the funding-privacy guardrails still pass — no cross-account union), change goes to BIP44/0, watch-only accounts are refused, and the fee is taken from the signed transaction rather than re-estimated.

Stacked on

Stacked on #4185, and includes #4247's commits.

The branch is based on #4185's head (port/v4.1/split-build-broadcast) with #4247's three commits (port/v4.1/send-raw-tx) cherry-picked beneath this change, because it needs both:

• feat(kotlin-sdk): split build/broadcast with reservation release for BIP70-style deferred submission #4185 supplies the signed-payment registry and the bfoss765/rust-dashcore pin at rev e99959ce — the ReservationToken / build_unsigned_reserved API this work is built on.
• feat(kotlin-sdk): single-account build_signed_payment send API (funding_path) #4247 supplies the build_signed_payment(funding_path) primitive itself, which is not present on feat(kotlin-sdk): split build/broadcast with reservation release for BIP70-style deferred submission #4185's branch.

Merge #4185 and #4247 first, then rebase this PR — its own contribution is the top two commits.

Two scoping notes for reviewers

1. The test-support commit is a verbatim carry of #4184's fixture — drop it on rebase once #4184 merges.

The receival tests need a wallet whose balance is split between BIP44 account 0 and a DashPay funds account, which WalletAccountCreationOptions::Default does not provision. That fixture — split_funded_wallet_manager_dashpay, DashpayLeg, and the foreign_contact_account_xpub helper — already exists in #4184's test_support.rs, and the last commit here (test(platform-wallet): DashPay-funded split wallet fixture…) is a verbatim copy of it, carried so this PR does not have to stack on 2.9k lines of unrelated asset-lock production code just to reach a test fixture. No production code from #4184 is included.

Once #4184 merges, drop that commit when rebasing — #4184's copy is the canonical one. The only intentional deviation is that the three items are #[cfg(test)]-gated here (ungated they would trip dead_code in a test-utils-only build of the FFI crate, since this crate's unit tests are their sole consumer); #4184 widens the consumer set, so its ungated copy supersedes this one cleanly.

2. De-contaminated from the source branch. On kotlinSDK-v4-qa3 the finalize commit and its parent had swapped pieces: the finalize commit carried the masternodes-by-voting-key JNI export (plus its read_id20 helper), while the parent carried this feature's external fun coreWalletBuildSignedPaymentWithToken declaration. This PR drops the masternodes bridge (its FFI half is not in this stack, so it would not build here) and includes the Kotlin declaration that belongs to it. The masternodes-by-voting-key feature is untouched and remains to be submitted on its own.

Tests

• cargo test -p platform-wallet --lib — 528 passed, 0 failed, no warnings. Includes all 11 wallet::core::send tests, all 20 wallet::signed_payment_registry tests, and all 3 wallet::funding_privacy::guardrail tests.
• cargo check -p platform-wallet-ffi -p rs-unified-sdk-jni — clean

Three new tests cover the receival funding path end to end, including reservation hold/release cycles:

• receival_funding_path_selects_signs_and_reserves_in_that_account
• receival_reservation_is_held_and_released_against_the_receival_account
• default_funding_reservation_is_held_and_released_on_bip44

References

• dashpay/platform issue Swift SDK: DashPay contact-received funds are unspendable (receival accounts unreachable by the send path) #4255 — the iOS counterpart of this defect ("Swift SDK: DashPay contact-received funds are unspendable (receival accounts unreachable by the send path)"). This PR is the Android/Kotlin side of the same fix.
• On-device verification (testnet, 2026-07-31): spend from a DashPay receival account, broadcast, and InstantSend lock all confirmed.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added support for building, signing, broadcasting, and releasing deferred Core payments.
  • Payments can use a selected funding account or derivation path and return fee, change, transaction, and reservation details.
  • Added reservation-token management for safely completing or abandoning payments.
  • Added clear handling for stale, consumed, and wallet-mismatched reservation tokens.

• Bug Fixes

  • Improved wallet-generation validation and reservation cleanup to prevent incorrect payment or reservation reuse.
  • Added insufficient-funds reporting with available and required amounts.