feat(platform): introduce protocol version 13

[QuantumExplorer]

What

Introduces protocol version 13, functionally identical to v12 — same component version structs throughout, no behavior change at introduction.

Why

Foundation for rolling-upgrade safety on #4142: recording shielded-spend transparent credits (Unshield / shield surplus / identity-create fallback) into the recent-address-balance-changes tree changes the committed state root, so it must not activate until validators agree — #4142 will be reworked to gate the new recording on v13, activated by the normal masternode version voting instead of requiring a lockstep deploy.

Changes

• v13.rs: exact clone of v12 (verified by diff: only the constant, the struct name, and the doc comment differ). Per repo convention, v12's inline "changed:" delta comments are dropped — they document deltas introduced at v12.
• Registration: mod.rs, protocol_version.rs imports, PLATFORM_VERSIONS array, LATEST_PLATFORM_VERSION → &PLATFORM_V13 (DESIRED_PLATFORM_VERSION follows by alias — drive-abci now advertises 13 to Tenderdash).

Deliberately unchanged (each checked individually)

• SDK per-network minimum floors (min_protocol_version: testnet/devnet/regtest = 12, mainnet = 11) — these are the currently running floors, not "latest"; they ratchet automatically when a network actually reports 13.
• feature_initial_protocol_versions — activation markers name the version where a feature turned on; v13 activates nothing at introduction (the fix(drive-abci): record unshield and shield-surplus credits in recent address balance changes #4142 follow-up adds its marker).
• Migration dispatch (perform_events_on_first_block_of_protocol_change) — v13 shares DRIVE_VERSION_V7, no new GroveDB structures, so a v12→v13 upgrade is correctly a no-op fallthrough.
• All PlatformVersion::get(12) / PROTOCOL_VERSION_12 test and doc references to v12-activation-specific behavior.

Verification

• cargo fmt --check clean; cargo check on platform-version, dpp, drive-abci, dash-sdk clean
• cargo test -p platform-version → 7 passed (incl. the shielded-pool v12 gating tests)
• cargo test -p drive-abci --lib protocol_upgrade → 42 passed (transition chains, same-version no-op, v12 tree creation)
• cargo test -p dpp state-transition range assertions (92) + validation-result (61) green — the ..=LATEST_VERSION ranges follow to 13
• cargo test -p dash-sdk version floor/ratchet/pin tests → 55 passed

🤖 Generated with Claude Code

[thepastaclaw]

✅ Final review complete — no blockers (commit c281488)

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 1 minute

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: 72253c4d-1f92-4f1a-a48f-463174a662a4

📥 Commits

Reviewing files that changed from the base of the PR and between b889e05 and c281488.

📒 Files selected for processing (3)

• packages/rs-platform-version/src/version/mod.rs
• packages/rs-platform-version/src/version/protocol_version.rs
• packages/rs-platform-version/src/version/v13.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/protocol-version-13

---

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]

Final validation — Codex + Sonnet

This PR mechanically registers protocol version 13 as an intentional byte-for-byte clone of v12, correctly wiring LATEST_PLATFORM_VERSION, PLATFORM_VERSIONS, and DESIRED_PLATFORM_VERSION, with v13 serving as an activation gate for a planned follow-up consensus change. The only in-scope issue is that advancing latest() to v13 causes three existing tests explicitly named for v11-to-v12 migration behavior to silently bind their platform_version_12 variable to PlatformVersion::latest() (now v13) instead of an explicit v12 lookup, which is harmless today but will quietly stop protecting the v12 boundary once v13 diverges as planned.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: claude-sonnet-5 — verifier
• Sonnet reviewers: claude-sonnet-5 — general (failed), claude-sonnet-5 — rust-quality (failed), claude-sonnet-5 — general (failed), claude-sonnet-5 — general (failed), claude-sonnet-5 — rust-quality (completed), claude-sonnet-5 — general (completed)

🟡 1 suggestion(s)

1 additional finding(s) omitted (not in diff).

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs`:
- [SUGGESTION] packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs:1084: Pin v12 migration tests to protocol version 12 explicitly
  Three tests explicitly named and structured to verify v11-to-v12 migration behavior (at lines 1084, 1376, and 1600) bind `platform_version_12` to `PlatformVersion::latest()` rather than an explicit version lookup. This PR advances `latest()` from v12 to v13, so these tests now silently exercise v13 dispatch instead of v12. Since v13 is deliberately identical to v12 today, the tests still pass, but this PR establishes v13 as the gate for a planned follow-up divergence. Once that lands, these tests will stop protecting the v12 migration boundary they claim to cover. A sibling test at line 1893 already uses `PlatformVersion::get(12).expect("expected v12")`. Pin all three to version 12 explicitly.