Release automation creates public tags/releases before RubyGems publication succeeds

Description of the bug

The installation incident in #2327 was resolved by subsequent releases. This report concerns the release ordering that can leave another public GitHub release/tag for a gem whose upload fails.

Checked current main (a95eb9abc9ce) on September 13. The release Gemfile pins toys-release 0.9.1. Its default pipeline runs release_github before release_gem, and this repository's configuration does not override that order.

Observed behavior

In run 33568604248, on September 1, 2026:

• At 22:55:53 UTC, GitHub release creation succeeded for opentelemetry-exporter-otlp-common/v0.1.0.
• At 22:56:03 UTC, gem push failed because a previous owner's yanked 0.1.0 already occupied that version.
• Three other gems published. Exporter 0.35.0 depended on the unavailable common gem; #2328 reverted that dependency and #2329 released the repair.

As of September 13, the 0.1.0 GitHub release remains public, while the RubyGems version inventory contains 0.2.0 but no installable 0.1.0. The registry rejection was external; creating the public release record before that rejection is the ordering problem here.

Expected behavior and possible fixes

Create a gem's public release/tag only after its publication succeeds. Two implementation options are:

1. Override the pipeline in this repository's release configuration so release_gem precedes release_github, retaining the existing build and documentation steps.
2. Make that ordering available/default upstream in toys-release, then update the pinned version here.

Either approach should preserve recovery when the upload succeeds but GitHub release creation fails: retry should verify the exact existing gem version and finish the release record without republishing or moving an existing tag. The current Retry release workflow and registry checks are useful foundations. Reordering alone does not make a blocked/yanked version reusable; that case still requires a valid new version or registry intervention.

A related safeguard is to publish and verify newly required gems before their dependents. That would prevent the dependent-install failure observed in #2327, which tag reordering alone would not prevent.

Suggested regression checks: inject a failed gem upload and assert that no public release/tag is created for that gem; inject a GitHub failure after successful upload and assert that retry completes only the missing record. These can use stubbed destinations without publishing test versions publicly.

Runtime and reproduction scope

The historical job used Ubuntu 24.04, Ruby 4.0.6, and toys-release 0.9.1. The evidence above comes from retained production logs, source, and registry metadata; no new production release was triggered for this report.

Disclosure: this report was prepared with AI assistance (Codex).

Start with .toys/release/Gemfile and .toys/.data/releases.yml, then inspect the current Retry release workflow and the pinned toys-release pipeline. Use stubbed destinations to test failed gem publication and failed GitHub release creation; done means no public release/tag follows an upload failure, while retry completes only a missing release record after a successful upload.