fix(wallet): require only atomic tracked-lock writes for reconciliation

[lklimek]

TL;DR

When a saved funding deposit is reported as already used, retain its recovery state and return the specific result instead of failing on an unrelated storage requirement.

User story

As a wallet user, I can understand why a saved deposit cannot fund another payment and check the earlier payment or choose another deposit.

Scenario

Choose Fund for a restored deposit that the network reports as already used. The recovery step updates the loaded deposit and saves that update atomically. It must not fail merely because the storage backend cannot restore unrelated wallet data.

Detailed discussion

Issue being fixed or feature implemented

Stacked on #5150 (fix/pr-5126). Integrated in dashpay/dash-evo-tool#1036. SQLite restores tracked asset locks but does not declare the broader WALLET_RESTORE capability. Asset-lock reconciliation previously required that capability despite operating on an already-loaded record.

What was done?

• Require ATOMIC_CHANGESETS | TRACKED_ASSET_LOCKS for asset-lock reconciliation, changing the operation mask from 0x281 to 0x201.
• Keep existing capability bit values and semantics. No new capability, stronger tracked-lock contract, or FFI callback requirements.
• Preserve typed already-consumed reports, nonterminal recovery state, proof checks, and rollback/persistence-failure handling. An unauthenticated consumed report is not proof of successful funding or a confirmed consumption tombstone.
• SQLite continues not to declare WALLET_RESTORE; full Core wallet restoration is implemented separately in stacked feat(wallet-storage): restore complete Core wallet snapshots from SQLite #5210, reusing fix(platform-wallet-storage)!: harden wallet history restore after #5150 review #5208.

Compatibility

No callback layout, capability version, or Swift/iOS integration changes. Backends need atomic writes and tracked asset-lock persistence for this operation.

How Has This Been Tested?

• 20 targeted Rust tests passed: 4 capability, 1 FFI callback admission, 3 SQLite reopen/manager hydration, and 12 typed-error/reconciliation tests.
• Scoped formatting, Clippy with CI's --no-deps -D warnings, and diff checks passed.
• No live user-wallet spending. Final net diff has no Swift changes.

Breaking Changes

None.

Checklist

• Self-review performed
• Relevant operation contract documented
• Focused regression coverage
• Validation limitations documented

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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 not started yet because this PR is a draft.

• Request normal review — click when the PR is ready for review.
• Request priority review — click to move this review to the front of the queue.

Commit f19cc0a. Normal review starts when eligible; priority review starts as soon as a slot is available.