rainix-autopublish pushes the version bump before publishing, so a failed publish permanently advances the version

[thedavidmeister]

rainix-autopublish commits and pushes the version bump before it runs the publish
steps. A publish that fails therefore leaves the bump on main permanently, and the next
run bumps again from there. The version advances on every failure while nothing is ever
published at that number.

Order in the workflow

.github/workflows/rainix-autopublish.yaml, by step:

~line	step
242	Bump Cargo version
250	Bump NPM version
261	Publish to Soldeer
297	Tag and push
336	Publish to crates.io
345	Publish to NPM

The bump is written and pushed at 297; crates.io and NPM are published at 336 and 345.

Observed consequence

rainlanguage/rain.math.float's @rainlanguage/float:

• Last version actually on the registry: 0.0.0-alpha.40, published 2025-12-01.
• No 0.0.x release was ever published.
• package.json in the repo has nonetheless crept 0.0.0 → 0.0.13.

Thirteen bumps, zero publishes. Each failed run pushed its bump and then errored at the
NPM step, so the number moved and the registry did not. The repository's version now
describes a release history that does not exist, and a reader cannot tell from the version
alone which numbers were ever published.

The same exposure applies to crates.io and to the Soldeer tag, which is created at 275
before the crates.io publish at 336. Soldeer happens to publish at 261, ahead of the push,
so a Soldeer-only repo is not affected — but that is ordering luck, not a guarantee.

What a fix has to preserve

The bump has to be computed before publishing, because the publish needs the number. What
does not have to happen before publishing is pushing it. Some options, not a ruling:

• Push the bump commit and tags only after every enabled publish step has succeeded.
• Or make the version derivation read the registry rather than the file, so a stale local
  number cannot compound — rainix-static's soldeer_gate already derives its version as
  max(patch_bump(published), next-v tag) rather than trusting a committed value, and the
  same shape would work here.

The second is the more durable one: it makes the committed number an output rather than an
input, so a divergence heals itself instead of accumulating.

Not in scope here

Why @rainlanguage/float's NPM publish returns E404 is a separate, credential-side
problem — tracked in rainlanguage/rain.math.float.deploy. This issue is only about the
ordering that turns any such failure into permanent version drift for every repo using
this workflow.