Custom builds for release workflows

[David Elner (delner)]

Adds a custom-build release path and reshapes the release actions around it, so a
repo that builds its own artifact gets the exact same security guarantees as the turnkey
flow.

What's new

• Two release shapes, identical guarantees: OIDC trusted publishing, an approval gate, a signed CycloneDX SBOM attested to the published artifact, and build provenance:
  • Turnkey — we build and publish in one gated job. The default.
  • Custom build ("build-ownership") — you build your own artifact; a publish-only job verifies it and publishes it. Same guarantees, without handing your build code the publish credentials.
• All three ecosystems: JavaScript (pnpm + Bun), Python, and Ruby, in both shapes.
• Reference workflows for every language × shape, ready to copy.
• Versioned actions: each action carries a machine-readable version so you can tell at a glance whether bumping to a newer commit is a safe (patch/minor) or breaking (major) change.

How to use it

1. Copy the reference workflow for your language and shape from .github/workflows/
   (release-<lang>.yml for turnkey, release-<lang>-custom.yml for custom builds).
2. Set up an OIDC trusted publisher on your registry (npm / PyPI / RubyGems).
3. Adapt the marked sections (package name, version source, working directory).
4. Pin the actions by commit SHA.

See the README for the full walkthrough.

Design

Both shapes are the same single-responsibility pipeline, cut at a different point.

Turnkey — one gated job builds and publishes:

bump → configure → prepare → validate → request-approval → [approval gate] → build-and-ship

Custom build — split into two jobs at the build⟷publish seam:

bump → configure → prepare → validate → pack → request-approval → [approval gate] → ship-package
                                        └── build side ──┘         └──────── publish side ────────┘
                                        unprivileged:                        gated:
                                        build + attest,                      verify the attestation,
                                        no publish credentials               publish the exact artifact

pack attests the artifact before uploading it and ship-package verifies that attestation after downloading, so tampering in transit fails verification and the publish is rejected.

[David Elner (delner)]

Added custom-build workflow dry runs to CI and also did real releases of both turnkey + custom workflows against the dummy packages. This should be good to go.