ci: create a GitHub Release on tag

[scarmuega]

Adds a release job to the tag-triggered pipeline so a GitHub Release is created automatically alongside the registry publish.

Why

Only go-sdk and haskell-sdk create GitHub Releases today; the other four pipelines end at publish. The result is that published packages have no corresponding release entry — python-sdk and rust-sdk had none at all, and dotnet-sdk / node-sdk had histories that simply stop where the May 2026 rewrite replaced the old workflows and dropped the step.

Today's tags were backfilled by hand. This makes it automatic.

Shape

release:
  needs: publish
  runs-on: ubuntu-latest
  permissions:
    contents: write
  steps:
    - uses: softprops/action-gh-release@v2
      with:
        generate_release_notes: true
        prerelease: ${{ contains(github.ref_name, '-') }}

Two deliberate choices:

• A separate job rather than a step inside publish. haskell-sdk does it inline, but on the OIDC pipelines (node-sdk, dotnet-sdk) publish runs with contents: read on purpose. Adding a release step there would mean widening the credential-bearing job to contents: write. Keeping it separate preserves least privilege, and the same shape is applied across all four repos for consistency.
• prerelease derived from the tag. A SemVer pre-release suffix is the only place a hyphen appears in these tags, so v1.8.0-alpha is marked pre-release and v0.9.0 is not, with no per-repo configuration.

needs: publish means no release entry appears if the registry push fails — the release reflects what actually shipped.

Scope

No change to verify, build, test, publish, the v* trigger, or any credential. Contract-wise this is additive: §2 mandates build/test/publish and §5 lists release notes as aspirational, so nothing was in violation — but the inconsistency is being closed deliberately, with a companion u5c-factory PR stating the requirement.

🤖 Generated with Claude Code