chore: bump rust-dashcore to the latest dev revision

[QuantumExplorer]

Issue being fixed or feature implemented

Moves the workspace's rust-dashcore pins up to the current head of dev, picking up the key rotation ChainLock signature fix (rust-dashcore#934).

That fix matters for us: feed_qr_info was collapsing each diff's quorumsCLSigs down to a single signature taken from the first rotating quorum it saw, then stamping the same 4-signature tuple onto every entry of the batch. The active rotation set can span several cycles at once, because a failed DKG leaves the previous cycle's quorum in place at that index, so every straggler got quarter modifiers built from another cycle's signatures. The reconstructed member sets then disagreed with the real signers and the whole QRInfo hard-failed with AllCommitmentAggregatedSignatureNotValid on the first fresh-sync response — permanently wedging masternode sync, ChainLock validation and InstantSend verification.

What was done?

Bumped all eight rust-dashcore workspace pins from 36b49cb7 to 173ffac0 and regenerated the affected Cargo.lock entries. Cargo.toml and Cargo.lock are the only files touched; both pin sites are workspace-level (packages/rs-platform-wallet only inherits via workspace = true), and no stale revisions remain anywhere in the tree.

The range is exactly one upstream commit. Alongside the signature keying it hardens several peer-controlled inputs in the same paths — an out-of-range quorum_index that sign-extended and underflowed the cycle base, a truncated lastCommitmentPerIndex that passed the trust gate, and whole-map cycle replacement that let one genuine commitment drop the other indices of a stored cycle. It also degrades individual quorums to Skipped rather than poisoning an entire feed when context is missing.

No platform source changes were needed. The reshaped surface — QRInfoFeedResult's new fields, find_rotated_masternodes_for_quorums returning a per-quorum Result, the new QuorumValidationError variants and the new qrinfo-capture feature — has zero call sites in this repo; every consumer lives inside rust-dashcore and dash-spv.

How Has This Been Tested?

• cargo check --workspace --all-targets — clean
• cargo check --workspace --all-features --all-targets — clean
• cargo test -p dpp --all-features — 3955 passed, 0 failed
• cargo test -p drive-abci --lib — 2670 passed, 1 failed

The single drive-abci failure is pre-existing and unrelated to this bump. test_data_contract_creation_fails_with_more_than_fifty_keywords fails with config version 0 is not supported, minimum version is 1; it passes in isolation, and the identical suite run against the base pin 36b49cb7 fails on the same test with the same counts (2670 passed / 1 failed). It is the latent PlatformVersion::set_current global test race — a concurrent test resets the global version mid-run and the contract serializes at config v0. Worth fixing, but separately from this bump.

Breaking Changes

None. No consensus-relevant platform behavior changes; the upstream fix corrects quorum reconstruction that previously failed outright.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas (n/a — no source changes)
• I have added or updated relevant unit/integration/functional/e2e tests (n/a — pin bump; existing suites run above)
• 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 (n/a)

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 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: 27 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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: f825a91f-4b26-4a1d-9556-49ea848005c3

📥 Commits

Reviewing files that changed from the base of the PR and between 0cb4bad and fa6aaec.

⛔ Files ignored due to path filters (1)

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

📒 Files selected for processing (1)

• Cargo.toml

---

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

[thepastaclaw]

ℹ️ Review superseded (commit fa6aaec)
Reason: PR merged before the review completed.
Last checked: 2026-08-13 09:19 UTC