fix(release): make harmont-cli crates.io-publishable (or drop the dead channel) and fix install docs

[markovejnovic]

Summary

The release workflow advertised cargo install harmont-cli (crates.io badge in README.md, the install.sh unsupported-platform fallback, and RELEASING.md) but the publish chain could never succeed. This PR completes the chain so the advertised crates.io install path actually works, rather than dropping the channel.

• hm-vm carried publish = false yet is a hard dependency of both hm-exec and harmont-cli. cargo refuses to publish a crate that depends on an unpublishable one, so cargo publish -p harmont-cli (and -p hm-exec) failed outright.
• release.yml never bumped or published hm-config, hm-render, or hm-exec; harmont-cli pinned them at 0.0.0-dev, which cannot resolve on crates.io.
• With the chain broken, cargo install harmont-cli was a dead install path.

What changed:

• Drop publish = false from hm-vm; add the required repository + description publish metadata.
• Stamp the tagged version into hm-config, hm-render, hm-vm, hm-exec and rewrite their workspace.dependencies pins alongside the existing ones.
• Add ordered cargo publish steps for hm-config, hm-render, hm-vm, hm-exec in dependency (topological) order before hm-plugin-cloud and harmont-cli.
• Add a publishability guard — cargo package --workspace runs before any real publish. It resolves sibling path deps locally (unlike cargo publish --dry-run, which would fail on the not-yet-indexed sibling deps) and fails fast on the publish = false / unpublished-dep regression class.
• Update RELEASING.md to describe the real 10-crate topologically-ordered chain and drop the stale hm-plugin-sdk reference.

A follow-up doc commit in this PR corrects one residual inaccuracy: RELEASING.md had described the guard as cargo publish -p harmont-cli --dry-run, but the workflow uses cargo package --workspace. The prose now matches the implementation.

Findings addressed

• crates-io-1 — hm-vm was publish = false while being a hard dep of publishable crates.
• crates-io-2 — hm-config / hm-render / hm-exec were never versioned or published; pinned at 0.0.0-dev.
• cargo-install-3 — cargo install harmont-cli was a dead install path.

Verification evidence

The publishability guard was run locally against the full workspace (the exact command the workflow runs before any publish):

$ cargo package --workspace --exclude hm-fixtures --allow-dirty --no-verify
   Packaging hm-util ... hm-pipeline-ir ... hm-plugin-protocol ... hm-vm ...
   hm-exec ... hm-render ... hm-plugin-cloud ... hm-dsl-engine ... harmont-cli
   (10 "Packaging" lines)
exit: 0

Result: all 10 publishable crates package cleanly, exit 0. The only warnings are cargo excluding tests/*.rs from the published packages, which is expected and benign.

Other checks:

• All 9 release.yml workspace.dependencies sed rewrites were replayed against Cargo.toml: every 0.0.0-dev pin is rewritten, none left behind (whitespace-exact match confirmed).
• hm-vm/Cargo.toml now carries repository.workspace = true + a description, satisfying crates.io's required-metadata check.
• .github/workflows/release.yml parses as valid YAML.

Judge verdict

Approved. Implementer verification passed: true. No blocking issues.

Needs human review

This PR wires the crates.io release/publish chain. The CRATES_IO_TOKEN repository secret is not set or modified here — only the workflow wiring that consumes it. A human must confirm the token exists with the correct scope (publish-new for the first release, then publish-update) before tagging a release. The first real publish is the only end-to-end proof that crates.io accepts the chain; this PR proves the local packaging precondition only.

---

Generated by the Harmont release-readiness workflow (automated; needs human review before merge). 🤖