fix(platform-wallet): keep prederived typed keys for legacy key-less rows + land the #893 crash-fix pin

[QuantumExplorer]

Issue being fixed or feature implemented

Two follow-ups that missed the #4129 merge window:

1. thepastaclaw's post-merge blocking finding on fix(swift-sdk): stored default on keyType so pre-column stores can migrate #4129 (review): the keyType stored default makes legacy stores openable, but legacy rows (persisted before feat(platform-wallet): persist typed BLS/EdDSA provider keys as core address rows #4127's typed-key column) decode with public_key: None and restore_address_pool's plain upsert then STRIPS the typed BLS key the gap-limit prederivation placed at the same index — silently breaking in-memory operator-ownership matching for pre-feat(platform-wallet): persist typed BLS/EdDSA provider keys as core address rows #4127 stores. The claimed "re-tags on every load" in the fix(swift-sdk): stored default on keyType so pre-column stores can migrate #4129 comment was also wrong (load only reads the snapshot; re-tag happens on the next persist pulse).

2. The rust-dashcore fix(dashmate): api binds to all interfaces #893 pin never landed on v4.1-dev: fix(swift-sdk): stored default on keyType so pre-column stores can migrate #4129 was merged minutes after opening, and the crash-fix pin commits were pushed to its branch afterwards. v4.1-dev still pins 38c689d9, leaving the dash-spv sparse-filter startup crash-loop (rust-dashcore#892) unfixed on mainline.

What was done?

• restore_address_pool: when an incoming row carries no key but the prederived entry at that index does, keep the existing typed key (no-op for post-feat(platform-wallet): persist typed BLS/EdDSA provider keys as core address rows #4127 rows, which always carry their key). Doc comment spells out why, and why legacy Ed25519 rows cannot be recovered this way (hardened-only; the old account-level batch's data was already dropped by the schema migration) — per the pre-release convention those stores re-derive on delete+re-import.
• New test legacy_keyless_row_keeps_prederived_typed_key pins the preservation and the inverse (a legacy row with no prederived counterpart stays key-less).
• Corrected the keyType doc comment to reflect actual re-tag timing.
• Bumped rust-dashcore to 19690d31 (the merged rust-dashcore#893, fixes rust-dashcore#892) — verified live earlier on the previously crash-looping simulator state (one-time discard + re-download, clean restarts since).

How Has This Been Tested?

cargo test -p platform-wallet -p platform-wallet-ffi — 468 + FFI suites, 0 failures, including the new legacy-preservation test. cargo check --all-targets clean. The pinned rust-dashcore rev is content-identical to the PR-head pin (828f707d) already exercised on both simulators.

Breaking Changes

None.

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

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@QuantumExplorer, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 43 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a7e58aa7-4a4d-411a-a49d-9186eb3e17b6

📥 Commits

Reviewing files that changed from the base of the PR and between f744652 and b1866bf.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (3)

• Cargo.toml
• packages/rs-platform-wallet-ffi/src/persistence.rs
• packages/swift-sdk/Sources/SwiftDashSDK/Persistence/Models/PersistentCoreAddress.swift

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/followup-4129-review-and-893-pin

---

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 in progress — actively reviewing now (commit b1866bf)