ci(release)!: one vX.Y.Z tag per release, built per network - testneton tag push, mainnet by promotion

[nol4lej]

Summary

Replaces release.yml with a release flow that builds one vX.Y.Z tag per release, once per network. The hyperbridge coprocessor is a compile-time feature, so testnet and mainnet need different binaries from the same tag.

-rc.N tags are retired. The binary reports <crate version>-<sha> to telemetry and --version, so the tag is now what operators actually see.

Behaviour

Trigger	Network	Image tags	GitHub Release
Tag push vX.Y.Z	testnet	X.Y.Z-testnet, testnet-latest	pre-release, testnet assets
Dispatch environment=mainnet, version=X.Y.Z	mainnet	X.Y.Z, latest	same release gains mainnet assets, becomes final
Dispatch environment=testnet	testnet	rebuilds the testnet flavour	—

A tag push always targets testnet. Mainnet is only ever a manual promotion.

Gates

• GPG signature verified on every run, promotions included. A tag that failed its testnet run still exists and could otherwise be promoted.
• Tag must equal the orbinum-node crate version, read at the tag rather than the checkout.
• Mainnet requires the testnet image X.Y.Z-testnet to exist.
• Mainnet docker-publish waits for the mainnet environment reviewer. Pushing latest is mainnet's rollout through Watchtower.
• github-release runs after docker-publish, so a rejected promotion cannot leave a final release for an image that was never pushed.
• Existing checks are kept: coprocessor read back off the binary, WASM size limit, checksums between jobs, the pushed image is run, and every pushed tag must resolve to the verified digest.

Fixes over the previous workflow

• The old workflow treated any tag without -rc as a release yet forced ENV=testnet. A v0.2.0 push would have published latest, 0.2.0 and 0.2 with a testnet-flavour binary.
• Testnet and mainnet builds can no longer share a registry tag (X.Y.Z-testnet vs X.Y.Z).

Compatibility

• runtime-upgrade.yml is unchanged. It already maps X.Y.Z-testnet → git tag vX.Y.Z for its provenance check, and still accepts historic -rc.N images.
• docs/DEPLOYMENT_FLOW.md describes this flow.