🔧 Harden SDK release workflows

[Robdel12]

Why

The CLI release is out, and the SDK releases are next. Before we run those workflows, the SDK release paths need to be a little more defensive so we do not burn a version number, publish without a matching GitHub asset, or trip over the Swift package's first real tag.

This keeps the release process boring: one SDK release at a time, generated notes when available, fallback notes when Codex-action has a bad day, and explicit checks that the target package version is still unpublished before we push tags or publish artifacts.

What changed

• Queues all SDK release workflows behind a shared sdk-release concurrency group so version commits and tags do not race each other on main.
• Lets SDK changelog generation fall back cleanly if the Codex release-note step fails.
• Verifies npm SDK target versions are unpublished before updating changelogs and publishing.
• Packs npm SDKs with npm pack --ignore-scripts, publishes that exact tarball, and attaches that exact tarball to the GitHub release.
• Adds Ruby release safety checks: refreshes to latest main, installs dependencies, runs bundle exec rake, verifies the gem version is unpublished, and fixes the Ruby changelog compare URL.
• Fixes Swift release version detection so [Unreleased] is ignored and the first real Swift tag can be created from 0.0.0 cleanly.

Verification

• git diff --check origin/main..HEAD
• Parsed all six changed workflow YAML files with Ruby's YAML loader.

[vizzly-testing]

Vizzly - Visual Test Results

CLI Reporter - Waiting for build

No builds received yet for this pull request.

CLI TUI - Approved

5 comparisons, no changes detected.

View build

---

_{rd/sdk-release-workflows · 9415084f}