Stabilize self-healing Rust crate release automation

[Teakowa]

Goal

Make WrightKit Rust crate releases a stable, low-maintenance CI contract that can recover automatically from a failed publication without manual version repair or release-specific workflow surgery.

Context

The shared release workflow runs release-plz release and release-plz release-pr on pushes to main, but consumer repositories currently set release_always = false. This makes publication depend on release-PR merge provenance in addition to registry state.

A concrete failure occurred in wrightkit/opy-rs: the v0.1.7 release PR was merged and the workspace version advanced to 0.1.7, but publication failed while the release secret path was being repaired. Later main runs saw local 0.1.7 > crates.io 0.1.6, yet release-plz release skipped because the current commit was not the release PR merge commit. The repository therefore could not self-heal from the already-correct version/registry mismatch.

Release automation is infrastructure and should prefer the standard registry-state-driven release-plz behavior over extra provenance state that can strand a repository after transient CI/auth failures.

Scope

• Make publication registry-state-driven so any later main run can publish an already-versioned but unpublished crate.
• Remove the release_always = false override from WrightKit crate consumers that use the shared workflow.
• Pin both the release-plz GitHub Action and release-plz CLI version in the shared reusable workflow so upstream releases do not silently change CI behavior.
• Update consumer workflow pins to the resulting shared workflow revision.
• Preserve the existing two-job release / release-pr structure and independent concurrency behavior.
• Preserve the current token-based publication path while keeping the shared workflow compatible with the existing release environment secret arrangement.

Non-goals

• Redesign versioning or changelog policy.
• Publish crates outside release-plz.
• Introduce repository-specific release workflows.
• Migrate to crates.io Trusted Publishing in this change. That requires crates.io-side trusted-publisher configuration for each crate and should be performed only when that external state is verified.

Acceptance criteria

• If main contains a package version that is not yet present on crates.io, a later main release run attempts publication regardless of whether that commit is the release PR merge commit.
• If all local package versions are already published, the publication job is a no-op and does not create a new version.
• Release PR creation remains automatic on main pushes.
• The shared reusable workflow pins the release-plz Action by immutable commit SHA and pins the release-plz CLI version explicitly.
• opy-rs and workshop-rs consume the stabilized contract and no longer opt out of release-plz self-healing behavior.
• Existing repository CI/release permissions, release environment usage, and publication serialization remain intact.

Ownership / dependencies

• wrightkit/.github owns the shared release workflow contract.
• Consumer repositories own only their release-plz policy and pinned shared-workflow revision.
• Consumer updates depend on the shared workflow revision created for this issue.

[Teakowa]

Implementation PRs opened:

• Owner contract: fix(release): stabilize shared release-plz tooling #31 — pins the release-plz Action by immutable SHA and CLI version explicitly.
• Consumer: fix(release): make publication self-healing opy-rs#121 — removes release_always = false and pins the stabilized shared workflow revision.
• Consumer: fix(release): make publication self-healing workshop-rs#132 — applies the same self-healing consumer contract.

Merge order: .github#31 first, then the two consumer PRs. The consumer PRs are Draft until the owner contract is merged. After opy-rs#121 merges, its main push is expected to retry the currently unpublished 0.1.7 from registry state.

[Teakowa]

Validated end to end.

• .github#31 established the pinned shared release-plz tooling contract.
• The first consumer integration incorrectly pinned the pre-squash PR head (7811de...), which GitHub did not resolve as the reusable workflow after the owner PR was squash-merged. The consumers were corrected to pin the merged owner revision 29733ebbe8ff39f38401d1dc93c3c680651f2a5b in opy-rs#122 and workshop-rs#133.
• opy-rs validated the recovery path: a later ordinary main push published the stranded opy-rs 0.1.7 and opy-cli 0.1.7, and created GitHub release v0.1.7.
• workshop-rs validated the no-op path: workshop-rs 0.1.16 and workshop-rs-cli 0.1.16 were detected as already published, release_output was empty, and both release jobs succeeded.
• Both consumers now use registry-state-driven release behavior and no longer set release_always = false.

The release pipeline now recovers unpublished local versions on a later main run while remaining a no-op for versions already present in the registry.