Shipper 0.3.0-rc.2 emits the publish plan in alphabetical-looking order
rather than topological order (EffortlessMetrics/shipper#173). With
\`uselesskey-aws-lc-rs\` at position 1 and \`uselesskey-core\` at #2,
shipper's linear walk fails immediately because cargo publish of
aws-lc-rs requires uselesskey-ecdsa (#22) and other deps to already be
on crates.io.

The owner of shipper will fix this in the next patch. Until then,
revert both \`release.yml\` and \`publish-retry.yml\` to use
\`cargo xtask publish\`. The PUBLISH_CRATES order is correct after #565,
and the test-helper dev-dep fix in #569 removes the cargo verification
gap that the original cargo xtask path also tripped over.

Keep \`.shipper/\` in \`.gitignore\` and the existing \`Quality gate\` /
\`Publish preflight\` / \`Publish dry-run\` steps in preflight job —
those are unaffected by the shipper revert and still useful.

After this PR merges, retag v0.7.0 on the new main HEAD and let
\`release.yml\` run end-to-end. shipper#173 stays open for the next
release cycle.

The v0.7.0 release lane failed because `[workspace.dependencies]` had
`version = "0.7.0"` declared on three internal `publish = false` crates
(`uselesskey-test-support`, `uselesskey-test-grid`,
`uselesskey-feature-grid`). Even though those entries were only consumed
as `[dev-dependencies]`, `cargo publish` resolves the workspace version
constraint against crates.io and fails with `no matching package named
...`. PR #569 stripped the offending `version` fields to fix the
instance, but the class of bug — a versioned workspace.dependencies
entry pointing at a non-publishable crate — could silently recur the
next time someone bumps versions across the manifest.

This adds `verify_no_versioned_publish_false_deps()`: it parses the
workspace `Cargo.toml`, walks every `[workspace.dependencies]`
inline-table entry that declares both `path` and `version`, opens the
referenced crate's `Cargo.toml`, and bails if `[package].publish` is
`false`. All violations are collected and reported together so the fix
is a single pass. The check is wired into both `publish_check()` and
`run_publish_preflight()` (as a new `preflight:publish-false-dep-guard`
step) so it runs ahead of any cargo packaging work and on the cheap
gate PRs already run.

A unit test asserts the function returns `Ok(())` on the current
workspace (post-#569). If anyone re-introduces a `version` field on a
path that resolves to a `publish = false` crate, the test and the
preflight gate both fail before a tag push can land.

The v0.7.0 release lane failed because `[workspace.dependencies]` had
`version = "0.7.0"` declared on three internal `publish = false` crates
(`uselesskey-test-support`, `uselesskey-test-grid`,
`uselesskey-feature-grid`). Even though those entries were only consumed
as `[dev-dependencies]`, `cargo publish` resolves the workspace version
constraint against crates.io and fails with `no matching package named
...`. PR #569 stripped the offending `version` fields to fix the
instance, but the class of bug — a versioned workspace.dependencies
entry pointing at a non-publishable crate — could silently recur the
next time someone bumps versions across the manifest.

This adds `verify_no_versioned_publish_false_deps()`: it parses the
workspace `Cargo.toml`, walks every `[workspace.dependencies]`
inline-table entry that declares both `path` and `version`, opens the
referenced crate's `Cargo.toml`, and bails if `[package].publish` is
`false`. All violations are collected and reported together so the fix
is a single pass. The check is wired into both `publish_check()` and
`run_publish_preflight()` (as a new `preflight:publish-false-dep-guard`
step) so it runs ahead of any cargo packaging work and on the cheap
gate PRs already run.

A unit test asserts the function returns `Ok(())` on the current
workspace (post-#569). If anyone re-introduces a `version` field on a
path that resolves to a `publish = false` crate, the test and the
preflight gate both fail before a tag push can land.