build/bake: inline GitHub runtime handling in workflows

[crazy-max]

fixes #210

This removes crazy-max/ghaction-github-runtime from the reusable build and bake workflows while preserving GitHub Actions cache signing behavior.

The prepare jobs now detect OIDC availability directly from process.env inside their existing actions/github-script setup logic. The build jobs expose only the OIDC request token and URL as masked step outputs for setup-buildx-action driver options.

This keeps the trusted workflow path inside Docker-owned workflow code and avoids depending on a third-party action just to surface runner-provided GitHub runtime values.

cc @stefanprodan

[stefanprodan]

LGTM

Thanks @crazy-max 🏅

PS. Unrelated to this change, I noticed that the container images pulled from DockerHub are not pinned by digest. Which can be deceiving as pinning the workflow does not actually propagate to the underlying tools like buildkit, binfmt, etc. Also actions-toolkit, unlike all others actions, this one is not pinned by hash.

[crazy-max]

PS. Unrelated to this change, I noticed that the container images pulled from DockerHub are not pinned by digest. Which can be deceiving as pinning the workflow does not actually propagate to the underlying tools like buildkit, binfmt, etc. Also actions-toolkit, unlike all others actions, this one is not pinned by hash.

Thanks for calling this out.

For the actions-toolkit part, I opened docker/actions-toolkit#1144 to harden how the npm package is published. The action is consumed from an exact package version and npm does not allow an already-published package version to be overwritten (we also have immutable tags enabled on actions-toolkit repo), but exact versions alone still leave transitive dependency resolution to the installer when a package doesn't ship a lockfile that npm honors.

The change generates the shrinkwrap during the publish workflow after npm version has aligned package.json with the release tag. It uses npm install --package-lock-only --ignore-scripts --omit=dev so the publish job resolves the production dependency tree and records registry integrity metadata without installing packages into node_modules or running dependency lifecycle scripts. The following npm shrinkwrap converts that lockfile into npm-shrinkwrap.json, which is the lockfile npm includes and honors for published packages. That means consumers of @docker/actions-toolkit get a pinned production transitive tree from the package itself, without requiring reusable workflow callers to have access to a lockfile from this repository.

This doesn't change the image digest point; those are separate follow-up hardening items for the workflow that we should take care of.

[thaJeztah]

LGTM