publish actions-toolkit with shrinkwrapped dependencies

[crazy-max]

This change hardens the published @docker/actions-toolkit package by making each release include an npm shrinkwrap for its production dependency tree.

The publish workflow now generates a production-only npm lockfile with lifecycle scripts disabled, converts it to npm-shrinkwrap.json, and publishes with provenance as before. The package file allowlist now includes npm-shrinkwrap.json so the generated shrinkwrap is shipped in the npm package.

This addresses the supply-chain concern raised in docker/github-builder#216 (review). Exact npm package versions are immutable, but publishing a shrinkwrap also pins the transitive dependency resolution that consumers get when they install @docker/actions-toolkit.

More info: https://docs.npmjs.com/cli/v11/configuring-npm/npm-shrinkwrap-json

[thaJeztah]

Looks like something isn't pinned;

[crazy-max]

Looks like something isn't pinned;

Yes was related to matrix subaction that had a unpinned dep but this is fixed in latest bake-action.

[crazy-max]

After thinking this through more, I'm not sure publishing an npm-shrinkwrap.json from @docker/actions-toolkit is the right tradeoff.

@docker/actions-toolkit is a shared library consumed by Docker action repositories such as docker/bake-action, not a standalone deployment artifact. npm treats npm-shrinkwrap.json differently from package-lock.json: package-lock.json is root-project-only, while npm-shrinkwrap.json is publishable and defines the dependency tree from the package downward. npm own docs call this out as something mainly suited for CLI/deployment-style packages rather than general libraries: https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json/#package-lockjson-vs-npm-shrinkwrapjson

For action repositories, the better boundary is that each action repo owns its full dependency graph through its committed lockfile and immutable install, then bundles the final action into dist. End users of an action like docker/bake-action don't install @docker/actions-toolkit at runtime, they run the bundled action code.

The concern that triggered this is still valid for docker/github-builder, but that is a different install surface. github-builder currently installs @docker/actions-toolkit dynamically inside the reusable workflow, so its transitive dependency resolution happens at workflow runtime. We should harden that path directly rather than pushing a shrinkwrap onto every library consumer.

The stronger long-term fix for github-builder is probably to stop doing ad hoc runtime npm installs and move the helper logic into a bundled action or another checked, pinned artifact. A short-term hardening path there would be to keep the exact @docker/actions-toolkit version, keep --ignore-scripts, avoid cache-preferred resolution, use --no-save, and consider npm audit signatures after install.

Given that, I put this PR back to draft and handle the github-builder npm install surface separately.