ci(workflows): pin build container images

[dc-tec]

Summary

• pin the manylinux and musllinux build images to immutable digests
• pin the multi-architecture .NET 8 Alpine SDK image used for package testing
• retain readable image tags alongside each digest

This covers 11 references to five unique images across the .NET, FFI, Go, and Node workflows.

Rationale

The workflows previously referenced mutable container tags. A registry publisher could therefore change the bytes used by pull-request and release builds without any corresponding repository change or review.

Zizmor reported eight high/high unpinned-images findings across the four matrix-container workflows. Pinning the resolved manifests makes image changes explicit and reviewable while retaining the original platform and compatibility tags.

No build behavior is intended to change beyond fixing the images to the versions the existing tags resolved to when this change was prepared.

Maintenance tradeoff

This trades silent upstream image drift for manual refreshes.

Dependabot currently only extracts repository-style uses: dependencies from GitHub Actions workflows. It does not update job-container matrix values or image references embedded in docker run commands. Adding a Docker ecosystem entry would not cover these workflow files either.

There are five unique images behind the 11 references, so a refresh is mechanical but must currently be initiated manually. I have intentionally not added another dependency bot or prescribed an update schedule in this PR.

A reasonable initial policy could be to refresh these pins during release preparation, in response to relevant security notices, or on an agreed periodic cadence. If that proves burdensome, a dedicated updater or consistency check can follow.

Dependabot support reference

Validation

• resolved every tag-plus-digest reference directly from its registry
• verified the PyPA image architecture mappings:
  • x86_64 images resolve to linux/amd64
  • aarch64 images resolve to linux/arm64
• verified the pinned .NET manifest contains both amd64 and arm64 variants
• devenv shell -- actionlint -shellcheck=
• devenv shell -- pre-commit run -a
• reran zizmor against the four affected workflows; the eight high/high unpinned-images findings are no longer reported

Zizmor still emits four low-confidence unpinned-images findings because it cannot statically prove that matrix.container only resolves to the pinned matrix values. The concrete values are all digest-pinned.

[dc-tec]

This looks like a flaky failing test, could you retrigger the failing jobs?