cargo's batch publish (`cargo publish -p manta-shared -p manta-cli`,
which is what cargo-release invokes) runs the verify step (~`cargo
build`) on each crate against the published crates.io index BEFORE
uploading any of them. manta-cli pins manta-shared with an `=`
lockstep version, so when the verify resolves the dep, crates.io
doesn't yet have the new manta-shared and the resolve fails:
failed to select a version for the requirement
`manta-shared = "=2.0.0-beta.35"`
candidate versions found which didn't match:
2.0.0-beta.34, 2.0.0-beta.32, ...
This is the same publish failure mode the user has hit on every
`cargo release beta -x` since the workspace-tag plan landed —
removing `tag = false` from manta-shared (commit 56c6e53b) was a
necessary fix but not sufficient; the verify step still chokes.
Set `verify = false` on the manta-cli `[package.metadata.release]`
block so cargo-release passes `--no-verify` to the batch publish.
cargo then uploads in topological order (manta-shared first, then
manta-cli) without verify, and each crate's actual compile +
test gating already runs in CI on every PR — verify-at-publish-
time was redundant insurance for the workspace anyway.