Cross-PR collision: the split-build-broadcast branch (dashpay#4185) already
allocates 26-28 for the reservation-token errors on the same base, and
both PRs would merge without textual conflict, silently misclassifying
errors on whichever lands second. Codes 26-28 are now documented as
reserved for dashpay#4185.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…the signer wire

Replace end-to-end message sniffing for the signer's "missing key" failure
with a typed discriminator (dashpay#4060 finding 7):

- rs-sdk-ffi: DashSDKSignerErrorCode { Generic = 0, SigningKeyUnavailable =
  1, AuthenticationFailed = 2 (reserved) }; SignCompletionCallback and
  dash_sdk_sign_async_completion gain error_code: i32 (before
  error_message). SignResult stays Result<Vec<u8>, ProtocolError> (a new
  rs-dpp ProtocolError variant would carry serialization blast radius), so
  code 1 rides the single Rust-owned machine prefix
  DASH_SDK_SIGNER_ERR_KEY_UNAVAILABLE_PREFIX through
  ProtocolError::Generic — typed at both ABI edges, one constant bridging
  the string segment. This is an internal coordinated ABI change: every
  piece versions together in this monorepo.
- rs-platform-wallet-ffi: PlatformWalletFFIResultCode::
  ErrorSigningKeyUnavailable = 31 (codes 26-28 are reserved for dashpay#4185's
  reservation-token errors and 29/30 for dashpay#4184's asset-lock errors on
  sibling branches — documented in the enum as dashpay#4184 does). The
  From<dpp::ProtocolError> conversion restores the typed code from the
  prefix FIRST (before the loose keyword sniffs), and the
  From<PlatformWalletError> blanket impl restores it on the catch-all only
  (dedicated retry-semantics codes are never overridden) — covering the
  Sdk(dash_sdk::Error::Protocol(..)) wrapping path.
- JNI/Kotlin: SignerNative.completeSign(token, signature, errorCode,
  errorMessage); KeystoreSigner passes SIGNER_ERROR_CODE_KEY_UNAVAILABLE on
  the null-key branch (keeping the MESSAGE_MARKER text for the transition
  window) and Generic everywhere else. DashSdkError maps 31 →
  PlatformWallet.SigningKeyUnavailable; the dashpay#4191 marker sniff on the
  catch-all codes remains as a deprecated old-native fallback with a
  removal note tied to the next minor release.
- Swift: KeychainSigner trampolines forward the code (missing-row /
  missing-scalar outcomes classify as 1); PlatformWalletResultCode gains
  errorSigningKeyUnavailable = 31 → PlatformWalletError
  .signingKeyUnavailable (Kotlin parity).
- Tests: rs-sdk-ffi completion-code tests (prefix present for code 1,
  absent for generic), platform-wallet-ffi prefix→31 tests on both
  conversion points, Kotlin code-31 + fallback-marker tests, Swift mapping
  and trampoline-classifier tests.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…roadcast

A pinned V2 finalized-transaction handle (core_wallet_tx_builder_finalize →
broadcast_finalized_transaction) had no reservation age guard, so a
long-held handle could broadcast against funding inputs that key-wallet's
ReservationSet TTL sweep may already have released and re-selected for an
unrelated build — the same stale-release hazard the deferred registry-token
path already defends against. This becomes live the moment iOS starts
issuing deferred sends (follow-up requested on PR dashpay#4185).

Mirror the registry-token age policy on the V2 handle path:

- Hoist RESERVATION_MAX_AGE_BLOCKS (20) and reservation_expired() from
  signed_payment_registry into wallet::reservations so both the registry
  and the V2 handle path bound a reservation's lifetime against key-wallet's
  TTL with one shared number.
- broadcast_finalized_transaction now refuses, before touching the
  broadcaster, once current last_processed_height - the reservation's stamp
  height (already carried on SignedCoreTransaction::reservation_height)
  >= the shared bound, returning the new token-less
  PlatformWalletError::StaleReservation. The stale reservation is left for
  key-wallet's TTL to reclaim (never released by outpoint, which could free a
  newer build's reservation). The check runs after the FFI layer's
  generation-identity check, matching the registry ordering.
- The FFI reuses the existing ErrorStaleReservationToken (26) code for this
  variant (documented as shared between the registry-token and V2-handle
  surfaces); no new codes allocated.
- Abandon/free (abandon_transaction) remain allowed at any age — releasing an
  old reservation is always safe.

Tests: fresh handle broadcasts; aged handle refuses with StaleReservation yet
still abandons cleanly and frees its inputs; exact boundary at the threshold
(BIP44/BIP32); FFI mapping of StaleReservation to the shared code.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

shumkov (PR dashpay#4185 follow-up) found the age guard covered only broadcast:
`abandon_transaction` — and therefore the `_v2_free` deinit/GC backstop and the
FFI broadcast/abandon failure paths that route their cleanup through it — still
released the funding reservation by outpoint unconditionally at any age. A
FinalizedCoreTransaction GC'd after ~1h whose outpoint was TTL-swept (24 blocks)
and re-reserved would free the newer build's reservation, letting its inputs be
re-selected into a third build (conflicting spends).

Honor `reservation_expired` in `abandon_transaction`, mirroring the registry's
`reconcile_removed_entry`: once aged past the shared `RESERVATION_MAX_AGE_BLOCKS`
bound, skip the by-outpoint release (leave the outpoint for key-wallet's TTL to
reclaim) while still tearing down the handle; below the bound, release as before.
This covers every consumer of `abandon_transaction`, including the `_v2_free`
GC-backstop and the FFI failure paths, off the same predicate/clock the
broadcast guard uses.

Also correct the reservation-policy docs that claimed releasing was always safe
(`reservations.rs`, `broadcast_finalized_transaction`), and the misleading
ManagedCoreWallet KDoc: after a stale-refused broadcast the handle is already
consumed, so `abandonTransaction` is an invalid-handle error, not a recovery —
the reservation waits out the TTL.

Tests: platform-wallet gains aged-skips-release / below-bound-releases pairs
(BIP44+BIP32); platform-wallet-ffi gains aged `_v2_free` and aged failure-path
skip-release tests via a new `age_core_past_reservation_guard` test helper.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…the signer wire

Replace end-to-end message sniffing for the signer's "missing key" failure
with a typed discriminator (dashpay#4060 finding 7):

- rs-sdk-ffi: DashSDKSignerErrorCode { Generic = 0, SigningKeyUnavailable =
  1, AuthenticationFailed = 2 (reserved) }; SignCompletionCallback and
  dash_sdk_sign_async_completion gain error_code: i32 (before
  error_message). SignResult stays Result<Vec<u8>, ProtocolError> (a new
  rs-dpp ProtocolError variant would carry serialization blast radius), so
  code 1 rides the single Rust-owned machine prefix
  DASH_SDK_SIGNER_ERR_KEY_UNAVAILABLE_PREFIX through
  ProtocolError::Generic — typed at both ABI edges, one constant bridging
  the string segment. This is an internal coordinated ABI change: every
  piece versions together in this monorepo.
- rs-platform-wallet-ffi: PlatformWalletFFIResultCode::
  ErrorSigningKeyUnavailable = 31 (codes 26-28 are reserved for dashpay#4185's
  reservation-token errors and 29/30 for dashpay#4184's asset-lock errors on
  sibling branches — documented in the enum as dashpay#4184 does). The
  From<dpp::ProtocolError> conversion restores the typed code from the
  prefix FIRST (before the loose keyword sniffs), and the
  From<PlatformWalletError> blanket impl restores it on the catch-all only
  (dedicated retry-semantics codes are never overridden) — covering the
  Sdk(dash_sdk::Error::Protocol(..)) wrapping path.
- JNI/Kotlin: SignerNative.completeSign(token, signature, errorCode,
  errorMessage); KeystoreSigner passes SIGNER_ERROR_CODE_KEY_UNAVAILABLE on
  the null-key branch (keeping the MESSAGE_MARKER text for the transition
  window) and Generic everywhere else. DashSdkError maps 31 →
  PlatformWallet.SigningKeyUnavailable; the dashpay#4191 marker sniff on the
  catch-all codes remains as a deprecated old-native fallback with a
  removal note tied to the next minor release.
- Swift: KeychainSigner trampolines forward the code (missing-row /
  missing-scalar outcomes classify as 1); PlatformWalletResultCode gains
  errorSigningKeyUnavailable = 31 → PlatformWalletError
  .signingKeyUnavailable (Kotlin parity).
- Tests: rs-sdk-ffi completion-code tests (prefix present for code 1,
  absent for generic), platform-wallet-ffi prefix→31 tests on both
  conversion points, Kotlin code-31 + fallback-marker tests, Swift mapping
  and trampoline-classifier tests.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Cross-PR collision: the split-build-broadcast branch (dashpay#4185) already
allocates 26-28 for the reservation-token errors on the same base, and
both PRs would merge without textual conflict, silently misclassifying
errors on whichever lands second. Codes 26-28 are now documented as
reserved for dashpay#4185.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…pay#4268 claimed

dashpay#4268 merged `ErrorShutdownIncomplete = 27` into the v4.2-dev
FFI ABI, colliding with the `ErrorStaleReservationToken = 27` this branch
carries alongside dashpay#4185. Renumber the deferred build/broadcast trio to the
contiguous block 34-36, matching dashpay#4185:

  ErrorStaleReservationToken      27 -> 34
  ErrorReservationTokenConsumed   28 -> 35
  ErrorReservationWalletMismatch  30 -> 36

34-36 sits above every code claimed by a merged commit or an open PR (27
dashpay#4268 merged, 29 dashpay#4184, 31 dashpay#4183/dashpay#4259, 32 dashpay#4247/dashpay#4256, 33 dashpay#4256), so it ends
the renumbering churn. 28 and 30 are vacated and return to the free pool.

This branch's own `ErrorTransactionBuild` (32) and `ErrorTransactionSigning`
(33) are unaffected; their numbering-rationale rustdoc is updated to name
dashpay#4268 as the owner of 27 and to record where the trio went.

Applied across the Rust enum, the FFI/JNI rustdoc, the Kotlin mapping + KDoc +
tests, and the Swift mirror (no compile-time cross-ABI check — verified by
grep).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

dashpay#4268 merged `ErrorShutdownIncomplete = 27` into the v4.2-dev
ABI on 2026-08-02, taking the number dashpay#4185 had held. dashpay#4185 and dashpay#4256 moved the
deferred-token trio to the contiguous block 34-36 in response.

Registry changes:

* 27 enters the merged table, owned by dashpay#4268.
* The proposed table moves the trio to 34/35/36 and marks 28 and 30 free but
  deliberately not reissued. Next free integer is now 37.
* New "Collision history" section records all three numberings of the trio
  (26/27/28 -> 27/28/30 -> 34/35/36) and, more usefully, corrects this file's
  own reasoning: on 2026-08-01 it recorded dashpay#3954's `ErrorShutdownIncomplete =
  27` as a non-conforming claim that had to be withdrawn because dashpay#4185's claim
  was older. Seniority among open PRs does not decide an ABI number — merging
  does. dashpay#3954 was closed, its work landed as dashpay#4268, and 27 is now merged ABI.
  The trio therefore moved above every claimed number rather than into the
  next free gap, so nothing currently in flight can hit it again.
* dashpay#3968's 27 is re-characterised: it was a proposed-vs-proposed collision, and
  is now a contradiction of merged ABI. Its frontier is 37+.
* dashpay#4196 is now two moves behind at 26/27/28; the doc reference it owns has to
  chase 34, not 27.
* Records a mirror gap found while grepping for this move: dashpay#4256 declares
  `ErrorTransactionBuild` (32) and `ErrorTransactionSigning` (33) in Rust and
  maps both in Kotlin, but declares neither in Swift, so both reach Swift hosts
  as `.errorUnknown`. Rule 5's Swift clause; left for that PR's author.
* Provenance re-verified against v4.2-dev `5d68612a45`, including the check
  that 32 and 33 were already taken — which is why the trio went to 34-36 and
  not 32-34.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…-> 37 and mirror it (dashpay#4204)

32 is allocated to `ErrorTransactionBuild` (dashpay#4247, also
carried by dashpay#4256) in ERROR_CODE_REGISTRY.md (dashpay#4261). This variant took 32
without a registry row, so the two collide as a hard `E0081: discriminant
value 32 assigned more than once` the moment both land — reproduced on a
real integration merge, not hypothetical. 27-36 are all claimed (27
ErrorShutdownIncomplete via the merged dashpay#4268; 29 dashpay#4184; 31 dashpay#4183; 32/33
dashpay#4247/dashpay#4256; 34-36 the dashpay#4185 trio) and 28/30 are vacated-but-RESERVED, so
37 is the allocation frontier.

The code was also unmirrored on BOTH hosts, which is the more dangerous
half: Swift is exhaustive, so it surfaced as .errorUnknown and lost its
identity; Kotlin fell through to Generic(32), and in any tree carrying
dashpay#4185's ErrorReservationWalletMismatch = 32 it actively MISCLASSIFIED
"shielded invite already claimed" as "reservation wallet mismatch". That
matters on the claim-recovery path specifically — the error is raised from
four sites in shielded/operations.rs, three inside the recovery function.

Adds the typed Kotlin PlatformWallet.ShieldedInviteAlreadyClaimed (terminal,
inherited isRetryable = false), the Swift enum case + init(ffi:) arm, a
DashSdkErrorTest assertion pinning 37, and refreshes the stale Swift
reservation comment the registry asked the next toucher to drop.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…e 32 collision

dashpay#4204 allocated 32 without a row here, colliding with dashpay#4247's
ErrorTransactionBuild. Caught for real during the v41int13 integration as an
E0081, not on paper — the first collision this file has actually stopped.
dashpay#4204 moves to 37; frontier advances to 38. Also records that the code was
unmirrored on both hosts, which had Kotlin misclassifying it as
ReservationWalletMismatch wherever dashpay#4185's 32 was present.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…keystore-qa4

Brings the ErrorShieldedInviteAlreadyClaimed 32 -> 37 renumber + host mirrors,
clearing the E0081 this integration hit against qa3's ErrorReservationWalletMismatch = 32.

Conflicts (4) all unions — kept BOTH sides, since this subset does not carry
dashpay#4185/dashpay#4256: the deferred-token trio stays at qa3's 27/28/32 and 37 is added
alongside. Swift's inherited comment was rewritten to describe THIS tree's
numbering rather than the 34-36 layout those branches introduce.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…, the code this integration actually uses

DashSdkErrorTest asserted offset+29 -> ReservationWalletMismatch, but 29 became
ErrorAssetLockInsufficientFunds when dashpay#4184 took it and the mismatch code moved
to 32 — so the assertion had silently stopped testing its own mapping on the
qa3 integration line. dashpay#4185/dashpay#4256 fix this by moving the trio to 34-36 and
updating the assertion; both are out of scope for v41int13, and no feature
branch carries ReservationWalletMismatch = 32, so this is corrected here.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…ilds

`build_signed_payment` reserves its selected inputs and leaves them
reserved on success, expecting a broadcast to follow. Nothing across
Rust/FFI/JNI/Kotlin let a caller that declines to commit give those
coins back, so an abandoned build stranded them for
RESERVATION_TTL_BLOCKS (24, ~1h) — and indefinitely while the wallet
has no processed height, since `ReservationSet::sweep` early-returns at
height 0 and therefore never reclaims a pre-sync reservation. A single
abandoned build on a freshly restored wallet could strand the whole
balance for the life of the process.

Adds a standalone release across all four layers:

  CoreWallet::release_payment_reservation(&Transaction, Option<DerivationPath>)
  core_wallet_release_payment_reservation (FFI)
  coreWalletReleasePaymentReservation (JNI)
  ManagedPlatformWallet.releasePaymentReservation (Kotlin)

The transaction is the ownership signal: a reserved outpoint is skipped
by every other build's coin selection, so no concurrent build can hold a
reservation on any input of the transaction being released — releasing
its inputs releases precisely this build's own reservation and can never
free a competing build's coins. Same signal the internal
`release_reservation_after_rejected_broadcast` cleanup already uses.

The release consults no height, so it works pre-sync where the TTL
backstop cannot. It is idempotent (per-outpoint map removal) and a
silent no-op after a successful broadcast — it cannot resurrect a spent
coin, since selection reads the UTXO set that sync already updated — so
callers can wire it into an unconditional cleanup path.

Also routes the build's default-funding-account resolution through the
shared `bip44_account_path` helper, so a release and its build can never
disagree about what `funding_path: None` means.

Tests: release-then-reselect (with the second-build failure pinned as a
precondition so it can't pass vacuously), release twice, release after a
processed broadcast, release against the wrong account frees nothing,
unknown funding path is refused, and the height-0 case — 30 build
attempts prove the TTL never fires there, then the explicit release
frees the inputs.

Addresses review item 3 on dashpay#4247. The reviewer's
suggestion to unify this with dashpay#4256's reservation-token finalize is
tracked separately rather than done here, to avoid reshaping an API the
Android app already calls and hard-coupling this PR to dashpay#4185.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…nd-path test fixtures

Restack adaptation only — no production-code change.

This branch now sits on top of dashpay#4185 (port/v4.1/split-build-broadcast)
rather than beside it. dashpay#4185 replaced the bare `Arc<WalletBalance>`
generation marker with `Arc<WalletGeneration>` (balance + that
generation's lifecycle gate in one Arc, so "same generation" and "same
gate" cannot diverge), and renamed `PlatformWalletInfo::balance` to
`::generation`.

The send-path test fixtures added here still built wallets the old way,
so they no longer compiled against the new base. Point them at the
shared `WalletGeneration` the rest of the crate already uses:

* `core/send.rs` — the local `core_wallet` fixture takes
  `Arc<WalletGeneration>`; `funded_wallet_manager` already hands one back.
* `wallet/funding_privacy.rs` — same, for its two fixtures.
* `test_support.rs` — the DashPay split fixture populates
  `PlatformWalletInfo::generation`.

cargo test -p platform-wallet -p platform-wallet-ffi: 537 + 230 pass.

…#4185's registry contract

Restack adaptation. This branch now sits on top of dashpay#4247 (which sits on
dashpay#4185) instead of beside them, so the funding-path registration meets the
contract dashpay#4185 established for the deferred-payment registry:

* `RegisteredPayment` keeps ONE funding handle — dashpay#4256's
  `funding: FundingAccountRef` — and dashpay#4185's MANDATORY
  `registered_height: u32`. The two evolutions are orthogonal (which
  account vs. which clock), so the union is a strict superset: the Path
  arm still reaches a DashPay receiving-funds account, and the age guard
  can no longer be silently disabled by a `None` height.
* `register_funded_by` therefore takes `registered_height: u32`.
  `FinalizedCorePayment::reservation_height` was already a non-optional
  `u32` sampled inside the funding critical section, so every caller
  simply drops its `Some(..)` wrapper — no behaviour change, one less
  way to disable the guard.
* `ReservationToken` is dashpay#4185's newtype; the FFI converts with `as_u64`
  at the C ABI boundary.
* The over-limit refusal binds the payment first and discharges its
  reservation through `abandon_payment` before returning, rather than
  stranding the account's coins until the TTL backstop.
* Test fixtures build wallets with `WalletGeneration` (balance + the
  generation's lifecycle gate in one Arc) and read
  `PlatformWalletInfo::generation`.

`register_funded_by` still cannot prove its `core` is the generation that
produced the payment the way `register` can — `FinalizedCorePayment`
carries no `origin_generation` marker, so the FFI's single
`generation_payment_guard` hold is what upholds the binding. That gap is
pre-existing on this branch and is documented on the method as follow-up.

cargo test -p platform-wallet -p platform-wallet-ffi: 540 + 230 pass.

…ode (33)

`map_send_builder_error` folded `BuilderError::SigningFailed` into
`TransactionBuild` → native code 32, whose documented contract is "the
request itself is at fault; a verbatim retry fails identically". That is
false for the production `MnemonicResolverCoreSigner`: a locked or missing
Keychain mnemonic surfaces as `SigningFailed`, and key-wallet
`release_if_owner`-releases the build's owner-stamped input reservation
before returning, so the identical recipients/amount/fee/funding path
succeed once the signer is usable. Hosts were being told to make the user
edit a payment that was never wrong.

Adds `PlatformWalletError::TransactionSigning` →
`ErrorTransactionSigning = 33` → `DashSdkError.PlatformWallet.TransactionSigning`
(isRetryable = true, matching the ShieldedNoRecordedAnchor convention for
"nothing committed, reservations released, retry once the precondition is
met").

Code choice — 33, not the reviewer's suggested 31. 27-32 are all claimed
across the sibling v4.1 stack (27/28 dashpay#4185, 29 dashpay#4184, 30 reserved for
free on every branch. 31 IS reserved, but for a different contract:
asserting the signer holds no usable private key for a requested public
key, restored from the typed `DashSDKSignerErrorCode::SigningKeyUnavailable`.
This is a Core L1 input signing failure with no such provenance —
`BuilderError::SigningFailed` also covers an unresolved input derivation
path, a sighash computation failure and a malformed signature encoding — so
reusing 31 would assert "the key is unavailable" for failures that are
nothing of the kind. Kept separate so neither contract is weakened; the
rationale is recorded on the variant for maintainers reconciling the range.

Tests: an end-to-end locked-signer build asserting TransactionSigning (not
TransactionBuild), a retry-after-recovery test proving the inputs really
were released, FFI code/mapping tests, and the Kotlin decode + retry-contract
test. platform-wallet 539 passed, platform-wallet-ffi 225 passed,
kotlin-sdk 190 passed; fmt clean, no new clippy warnings.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Keeps this branch on top of dashpay#4185, which has just taken current v4.2-dev
(post-dashpay#4268). Sole conflict: `platform-wallet-ffi`'s result enum, where
dashpay#4268 adds `ErrorShutdownIncomplete = 27` and this branch adds
`ErrorTransactionBuild = 32`. Both kept, declared in numeric order; no
renumbering was needed because 32 was chosen from the registry frontier
with 27 already reserved to dashpay#4268.

Keeps this branch on top of dashpay#4247, which now carries current v4.2-dev
(post-dashpay#4268). Merged cleanly — dashpay#4268's coordinator-lifecycle rework and
this branch's funding-path finalize touch disjoint code, and the error
space was already reconciled to the registry (dashpay#4261): 27
ErrorShutdownIncomplete (dashpay#4268), 32 ErrorTransactionBuild (dashpay#4247), 33
ErrorTransactionSigning (this PR), 34-36 the dashpay#4185 deferred-token trio.

Cross-PR collision: the split-build-broadcast branch (dashpay#4185) already
allocates 26-28 for the reservation-token errors on the same base, and
both PRs would merge without textual conflict, silently misclassifying
errors on whichever lands second. Codes 26-28 are now documented as
reserved for dashpay#4185.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

 review blocker 2)

Reviewer (thepastaclaw) blocker 2 — build.rs:423-424:
build_asset_lock_tx_from_selected_account passed the BIP44 change
account (&bip44_acc) as set_funding's `acc`, but set_funding calls
funds_acc.next_change_address(Some(&acc.account_xpub)) on the SELECTED
funds account before the set_change_address override. For an explicitly
selected Standard BIP32 account with no pre-generated unused internal
address, that derived [1, index] from the wrong (BIP44) xpub and recorded
it under the BIP32 account's own path, poisoning that pool so a later
normal BIP32 send could use a change entry whose signer key does not match
the address. Now resolve the wallet-level Account whose account-level
derivation path equals funding_path and pass ITS xpub to set_funding,
while keeping the separate BIP44 set_change_address override. Default
BIP44 funding resolves to bip44_acc (unchanged); non-Standard
(CoinJoin/DashPay) accounts fail change derivation regardless, so the
xpub is immaterial and the bip44_acc fallback preserves prior behavior.

Also (thepastaclaw nitpick, test_support.rs): move the DashPay fixture
rustdoc so it attaches to split_funded_wallet_manager_dashpay rather than
foreign_contact_account_xpub.

Blocker 1 (build.rs:427-473, owner-guarded reservation rollback on the
pre-broadcast abandonment path) is NOT addressed here: the pinned
key-wallet rev 70d4bf8 exposes no owner-guarded release primitive
(ReservationSet has only reserve/reserved/release keyed by outpoint;
release_reservation is unconditional) and no reservation token, so the
required release_if_owner(token) mechanism (rust-dashcore#916 / dashpay#4185)
cannot be implemented against this pin without an upstream dependency
change — the very atomic-reservation fix this PR is held for. Deferred
pending that adoption rather than substituting an unconditional release
on the money path.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…the signer wire

Replace end-to-end message sniffing for the signer's "missing key" failure
with a typed discriminator (dashpay#4060 finding 7):

- rs-sdk-ffi: DashSDKSignerErrorCode { Generic = 0, SigningKeyUnavailable =
  1, AuthenticationFailed = 2 (reserved) }; SignCompletionCallback and
  dash_sdk_sign_async_completion gain error_code: i32 (before
  error_message). SignResult stays Result<Vec<u8>, ProtocolError> (a new
  rs-dpp ProtocolError variant would carry serialization blast radius), so
  code 1 rides the single Rust-owned machine prefix
  DASH_SDK_SIGNER_ERR_KEY_UNAVAILABLE_PREFIX through
  ProtocolError::Generic — typed at both ABI edges, one constant bridging
  the string segment. This is an internal coordinated ABI change: every
  piece versions together in this monorepo.
- rs-platform-wallet-ffi: PlatformWalletFFIResultCode::
  ErrorSigningKeyUnavailable = 31 (codes 26-28 are reserved for dashpay#4185's
  reservation-token errors and 29/30 for dashpay#4184's asset-lock errors on
  sibling branches — documented in the enum as dashpay#4184 does). The
  From<dpp::ProtocolError> conversion restores the typed code from the
  prefix FIRST (before the loose keyword sniffs), and the
  From<PlatformWalletError> blanket impl restores it on the catch-all only
  (dedicated retry-semantics codes are never overridden) — covering the
  Sdk(dash_sdk::Error::Protocol(..)) wrapping path.
- JNI/Kotlin: SignerNative.completeSign(token, signature, errorCode,
  errorMessage); KeystoreSigner passes SIGNER_ERROR_CODE_KEY_UNAVAILABLE on
  the null-key branch (keeping the MESSAGE_MARKER text for the transition
  window) and Generic everywhere else. DashSdkError maps 31 →
  PlatformWallet.SigningKeyUnavailable; the dashpay#4191 marker sniff on the
  catch-all codes remains as a deprecated old-native fallback with a
  removal note tied to the next minor release.
- Swift: KeychainSigner trampolines forward the code (missing-row /
  missing-scalar outcomes classify as 1); PlatformWalletResultCode gains
  errorSigningKeyUnavailable = 31 → PlatformWalletError
  .signingKeyUnavailable (Kotlin parity).
- Tests: rs-sdk-ffi completion-code tests (prefix present for code 1,
  absent for generic), platform-wallet-ffi prefix→31 tests on both
  conversion points, Kotlin code-31 + fallback-marker tests, Swift mapping
  and trampoline-classifier tests.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>