chore: let cargo-release own the version bump

[LKSNDRTMLKV]

Prepares main so the documented one-command release produces 0.10.0.

The problem this fixes

I had bumped Cargo.toml to 0.10.0 by hand in #43. But RELEASE.md's command is

cargo release minor --workspace --exclude dpp-benches --execute

and cargo-release performs the bump itself. Run against a main already at
0.10.0, that would have bumped again and shipped 0.11.0.

What changed

• Cargo.toml + Cargo.lock back to 0.9.0. cargo release minor now bumps
  0.9.0 → 0.10.0, matching the [0.10.0] - 2026-07-20 section already in the
  changelog, and produces the release commit and v0.10.0 tag in one pass.
• Publish order corrected. dpp-calc was listed 7th as "depends on
  dpp-domain". It has no workspace dependencies at all and belongs in the first
  wave. dpp-registry also depends on dpp-rules, not just dpp-domain.

The changelog is deliberately left declaring 0.10.0 while Cargo.toml says
0.9.0 — that is the normal cargo-release shape (changelog prepared ahead, tool
bumps at release time), and no pre-release-replacements are configured, so the
tool will not touch it.

Release command

cargo release minor --workspace --exclude dpp-benches --dry-run   # always first
cargo release minor --workspace --exclude dpp-benches --execute

Pre-publish checks already done

Item	Result
fmt / clippy --all-features / tests --all-features / doc / audit	clean
Doc-tests	pass
TODO/FIXME in crates	none
READMEs	no stale version references
Crate metadata (description, license, keywords ≤5)	complete on all 8 publishable crates
LICENSE bundled per crate	present
publish = false on dpp-tests and dpp-benches (pinned 0.0.0)	correct
cargo package --list -p dpp-domain	all 20 embedded schemas included

Note on cargo-semver-checks: running it after a 0.9→0.10 bump is vacuous —
that is already a semver-major step for a 0.x crate, so it skips every lint
("0 checks: 0 pass, 253 skip"). With the version restored here it has a real
baseline again. Reading the diff directly, the only public API change since
0.9.0 is additive (dpp_rules::canonical); PROTECTED_PATCH_FIELDS is private,
and bundle::verify::content_hash kept its signature. The minor bump is driven
by the behavioural lintResult tier change, which semver-checks cannot see.

[LKSNDRTMLKV]

Closing — this reverted a bump that was already correct and turned a one-step publish into a multi-step one. main is at 0.10.0 and ready to ship as-is. The RELEASE.md publish-order correction it also carried will come back as a separate follow-up after the release.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}

[codacy-production]

Pull Request Overview

The pull request is currently 'up to standards' according to Codacy, but it fails to meet its primary acceptance criteria. Most significantly, the file changes required to revert the workspace version to 0.9.0 ('Cargo.toml' and 'Cargo.lock') are not included in the PR.

Furthermore, there is an implementation gap in the documentation: 'RELEASE.md' instructs the user to execute a 'patch' release, which contradicts the goal of performing a 'minor' bump to reach 0.10.0. These issues should prevent merging until the missing files are included and the documentation is aligned with the intent.

About this PR

• Major implementation gap: The changes to 'Cargo.toml' and 'Cargo.lock' mentioned in the PR description are missing. The version revert is necessary for 'cargo-release' to function as intended.

1 comment outside of the diff

docs/governance/RELEASE.md

_{line 69-72 🔴 HIGH RISK}
The documentation still instructs users to run 'cargo release patch' (lines 69, 72). To achieve the stated goal of a version bump to 0.10.0, this command should be updated to 'cargo release minor'. Running a patch release on 0.9.0 would result in 0.9.1.

Test suggestions

• Found recommended test scenario: Verify publication order in 'RELEASE.md' is a valid topological sort of the workspace dependency graph
• Missing recommended test scenario: Verify 'cargo release minor --dry-run' correctly calculates the next version as 0.10.0

Prompt proposal for missing tests

Consider implementing these tests if applicable:
1. Missing recommended test scenario: Verify 'cargo release minor --dry-run' correctly calculates the next version as 0.10.0

_{TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback}