ci: switch to docker/github-builder to build and sign

[crazy-max]

This PR moves package builds onto docker/github-builder and keeps the release image layout aligned with the signed metadata that the builder now produces. Builds now publish package artifacts with signed provenance and Sigstore bundle material.

The first commit reworks the reusable build workflow so each distro package build is delegated to docker/github-builder, with Bake variables passed through the workflow input and package verification kept in this repository. The second commit updates hack/release.Dockerfile so release metadata files are emitted next to each package using the package artifact basename, such as:

• docker-buildx-plugin-0.35.0-1.el10.x86_64.provenance.json
• docker-buildx-plugin-0.35.0-1.el10.x86_64.sigstore.json
• docker-buildx-plugin-0.35.0-1.el10.x86_64.sbom.json

Using docker/github-builder centralizes runner handling, SBOM generation, provenance generation, and OIDC-backed signing instead of carrying that logic in the packaging workflow. Naming release metadata after the package artifact makes the release image easier to consume because every SBOM, provenance file, and Sigstore bundle is tied directly to the package it describes.

Package builds now enable signing outside pull requests, which causes the builder to produce signed provenance and Sigstore verification material for the package artifacts. This gives release consumers a clear path from the package file to its SBOM, provenance, and signature bundle without relying on shared generic filenames in each release directory.

A follow-up should look at appending the Sigstore bundle directly into the package artifacts themselves. Keeping the bundle next to the packages is a good first step, but embedding or attaching the verification material at the package format level would make distribution and verification less dependent on external sidecar files.

[vvoland]

Can the separate stages be nested so we only have 1 entry per platform?

[crazy-max]

Can the separate stages be nested so we only have 1 entry per platform?

I don't think GitHub Actions can render this as true nesting with the current workflow shape.

We have two reusable workflow levels here: packaging calls build/release, then build/release calls docker/github-builder. GitHub flattens jobs from nested reusable workflows in the run UI, so the internal prepare, build, and finalize jobs from each github-builder invocation show up as sibling jobs.

This looks like a known Actions UI limitation. There is a related Community discussion here: https://github.com/orgs/community/discussions/186872. There is also a broader feature request for a structured reusable workflow dependency view here: https://github.com/orgs/community/discussions/51496.

That is why I added job-name-prefix in docker/github-builder#249 and pass the distro name from this PR. It's not real UI nesting, but it makes the flattened jobs readable while keeping the build/signing/attestation logic centralized in github-builder.