autopublish: chained per-crate jobs conflict on shared dependent manifest (need single combined job)

[thedavidmeister]

Problem

For a repo with interdependent workspace crates published via multiple rainix-autopublish callers chained with needs: (e.g. rain.metadata: bindings → metaboard, with cli depending on both), the per-crate release jobs conflict when more than one crate genuinely changes in the same push.

Each job runs cargo release, which doesn't only bump its own crate — it rewrites the dependent manifests that pin it. The cli crate pins both rain-metadata-bindings and rain-metaboard-subgraph versions, so:

• the bindings job bumps crates/cli/Cargo.toml's bindings pin and pushes,
• the metaboard job's bump edits crates/cli/Cargo.toml's metaboard pin,
• rebasing the metaboard bump onto the bindings push conflicts in crates/cli/Cargo.toml (not just Cargo.lock).

Observed (run 26455937109):

CONFLICT (content): Merge conflict in crates/cli/Cargo.toml
error: could not apply 6558055... chore: Release
error: key with no value, expected `=`   # conflict markers broke the TOML

The #184 rebase fix only auto-resolves Cargo.lock; #187 (User-Agent) only stops no-op crates from pushing, which sidesteps the conflict only while at most one crate actually changed. Two real changes at once still collide.

Proper fix

Publish all of a repo's crates from a single combined job in dependency order: one cargo release --workspace-style bump (or sequential bumps with no intermediate push), one commit, one push, then publish each crate. No chained jobs pushing to the same branch, so no rebase/conflict surface.

This changes the consumer contract (one caller instead of N chained callers) — consumers like rain.metadata, rainlang would pass a list of crates in dependency order.

Context

• Race + Cargo.lock rebase: fix(autopublish): rebase before push so chained release jobs don't race #184
• Hash-gate content comparison: fix(autopublish): content-based cargo change detection (stop re-bump churn) #186
• crates.io User-Agent workaround: fix(autopublish): send crates.io User-Agent (workaround for change-detection churn) #187
• Downstream symptom: Package Release: sequential autopublish jobs race on git push to main rain.metadata#120

Done when

• A repo where 2+ interdependent crates change in one push publishes all of them, with all version bumps + dependent-pin updates, in a single push with no rebase conflict.