docs: align release skill and release.toml with CI-based crates.io publishing

[zawakin]

Why

The release skill (.claude/commands/release.md) documented a flow where cargo release --execute publishes to crates.io locally (with cargo login as a prerequisite). In reality, .github/workflows/release.yml has a publish-crates job that publishes all crates in dependency order via the CARGO_REGISTRY_TOKEN secret on tag push — and it has been the actual publish path (v0.7.0/v0.7.1/v0.8.0 all published this way).

Worse, the mismatch is a footgun: release.toml had publish = true, so a successful local publish would make CI's cargo publish fail with "already uploaded" and block the entire release workflow, including the GitHub Release. During the v0.8.0 release this only surfaced as a confusing mid-release stop at the missing-token error.

What

• release.toml: set publish = false with a comment explaining that CI owns publishing. cargo release --execute now does bump → commit → tag → push only, and the tag push hands off to CI.
• .claude/commands/release.md:
  • New "How releasing works" section describing the local/CI split, with an explicit "do NOT publish locally / no cargo login needed" warning
  • Removed the cargo login prerequisite; added brew install option for tools
  • Dry-run no longer needs --no-verify (packaging/verify only ran because of local publish), so the "no hash listed" troubleshooting entry is replaced
  • Step 5 now includes a gh run watch command for the CI release workflow
  • New troubleshooting entries: resuming a half-finished release with cargo release tag / cargo release push step subcommands, and what "already uploaded" in publish-crates means

Verification

• cargo release --workspace patch dry-run now plans version bump + push only — no Packaging/Uploading steps
• v0.8.0 was released end-to-end through exactly this flow: local bump/tag/push, then CI published crates.io + npm + GitHub Release (17 assets), all green

🤖 Generated with Claude Code