ghcr.io/actions/actions-runner:2.336.0 Docker image is missing node24 in externals/, even though the release tarball for the same version includes it

The ghcr.io/actions/actions-runner Docker image for 2.336.0 doesn't contain a node24 runtime under /home/runner/externals/, even though node24 is present in the official release tarball for the exact same version, and src/Misc/externals.sh at the v2.336.0 tag explicitly downloads it for every platform.

This breaks any action declaring using: node24 (e.g. actions/checkout@v6) when run via gha-runner-scale-set's Kubernetes container mode, since actions/runner-container-hooks mounts the runner's own externals volume directly into the job container at /__e (no copy step, no per-version list — confirmed by reading packages/k8s/src/k8s/utils.ts / index.ts) — whatever's missing from the runner image is missing in the job container too.

Repro

Using ghcr.io/actions/actions-runner:2.336.0 (also reproduces on :latest, same digest) via gha-runner-scale-set v0.14.2, containerMode.type: kubernetes, running a workflow with a job-level container: and actions/checkout@v6:

env: '/__e/node24/bin/node': No such file or directory
##[error]Error: failed to run script step: command terminated with non-zero exit code: error executing command [sh -e ...], exit code 127
##[error]Executing the custom container implementation failed. Please contact your self hosted runner administrator.

Evidence the Docker image itself is missing it (not a hooks issue):

$ crane export ghcr.io/actions/actions-runner:2.336.0 - | tar -tf - | grep '^home/runner/externals/' | awk -F/ '{print $3}' | sort -u
node20
node20_alpine

(same result for --platform linux/amd64 and --platform linux/arm64)

Evidence the release tarball for the same version does include it:

$ curl -sL -o runner.tar.gz \
  https://github.com/actions/runner/releases/download/v2.336.0/actions-runner-linux-arm64-2.336.0.tar.gz
$ tar tzf runner.tar.gz | grep '^\./externals/' | awk -F/ '{print $3}' | sort -u
node20
node20_alpine
node24

Evidence src/Misc/externals.sh at the v2.336.0 tag already downloads node24 for linux-arm64:

$ curl -s "https://raw.githubusercontent.com/actions/runner/v2.336.0/src/Misc/externals.sh" | grep -A2 'linux-arm64'
if [[ "$PACKAGERUNTIME" == "linux-arm64" ]]; then
    acquireExternalTool "$NODE_URL/v${NODE20_VERSION}/node-v${NODE20_VERSION}-linux-arm64.tar.gz" node20 fix_nested_dir
    acquireExternalTool "$NODE_URL/v${NODE24_VERSION}/node-v${NODE24_VERSION}-linux-arm64.tar.gz" node24 fix_nested_dir

Given the release tarball has it and the source that builds that tarball already includes it, the gap looks like it's specifically in how images/Dockerfile / the image publish pipeline builds/packages the Docker image — possibly building from a stale cached runner tarball, or a build/publish step running against an older commit than the tag it's published under.

Environment

• actions-runner image: 2.336.0 (ghcr.io/actions/actions-runner:2.336.0, also :latest — same digest sha256:0cfdcc701ce933c6d243c6b0b2da767366dc9f2e99961d4c3754b0b78084cdda)
• gha-runner-scale-set / gha-runner-scale-set-controller: 0.14.2
• containerMode.type: kubernetes
• Platform: self-hosted Kubernetes (Talos, arm64), also reproduced against linux/amd64 image variant

Start with images/Dockerfile and the image build/publish inputs, then compare them with src/Misc/externals.sh at the v2.336.0 tag and the release tarball. Verify the resulting amd64 and arm64 images contain /home/runner/externals/node24, then rerun the Kubernetes container-mode workflow with actions/checkout@v6 and confirm the missing-runtime error is gone.