build(backend): pin base image to node 24.19.0 by digest

[marians]

What does this PR do?

Pins the backend image's base from the floating node:24-trixie-slim to a full version plus digest:

FROM node:24.19.0-trixie-slim@sha256:0711b541c1c33a8a530ac4f0d391baa9a15b3d804695b1b24a47daa5fb60e74d

24-trixie-slim is republished whenever Debian ships security updates into the -slim base, which has two consequences:

1. The Node runtime we deploy can change without any commit here. The tag also currently aliases lts-trixie-slim, so a future Node LTS transition would move it across a major.
2. It guarantees a cold image build on that run. A moved FROM digest invalidates every layer beneath it, so no Docker layer cache can survive it.

What is the effect of this change to users?

None. 24-trixie-slim resolves to 24.19.0 at digest 0711b541… right now, so this pin is byte-identical to what we already ship. It only makes the version explicit and moves future base-image changes into reviewable Renovate PRs instead of arriving unannounced.

Any background context you can provide?

Found while measuring the image build for giantswarm/architect-orb#871, which adds a BuildKit registry layer cache to push-to-registries. Two builds of an unchanged yarn.lock three days apart were both fully cold, because node:24-trixie-slim had been republished at 2026-08-05T08:39:10Z in between. With the layer cache that difference is ~2m vs ~5m30s on push-to-registries; without a pin the cache is only useful between upstream republishes.

This is worth doing on reproducibility grounds regardless of whether that orb change lands.

Verified:

• The pinned reference resolves and its index still carries linux/amd64 (plus arm64/ppc64le/s390x) — mediaType: application/vnd.oci.image.index.v1+json.
• hadolint output is unchanged from main (same four pre-existing DL3008/DL3013/DL3042/DL3066 findings, no new ones). Pinning is what DL3006/DL3007 ask for.
• Renovate will keep both the version and the digest current: the shared renovate-presets:default.json5 enables the dockerfile manager, its ignorePaths don't cover packages/backend/Dockerfile, and the only pinDigests: false rule is scoped to Giant Swarm-owned GitHub Actions.

One observation, not addressed here: CI builds with cimg/node:24.18.0 (.circleci/workflows.yml) while the runtime image is now explicitly 24.19.0. That minor mismatch already exists today — it was just invisible while the runtime floated. Worth aligning separately if we want build and runtime on the same Node.

Do the docs need to be updated?

No.

Should this change be mentioned in the release notes?

• A changeset describing the change and affected packages was added.

Not applicable — changesets cover the published @giantswarm/backstage-plugin-* packages, and this touches only packages/backend's Dockerfile. The app image and Helm chart release from the conventional-commit PR title via git-cliff, where build: lands in "Changed" with a patch bump.

[marians]

node-build is red here, but not because of this change — this PR touches only packages/backend/Dockerfile, which node-build never reads.

main itself is red (pipeline 9562): yarn install --immutable fails with YN0028, because the grafana bump in #2046 left seven now-unreferenced @backstage/* descriptors in yarn.lock. This branch is based on 5d31d0be and inherits it.

Fix is in #2048 (pure prune: 173 deletions, no version changes). I'll rebase this PR once that lands, so its CI actually exercises the pinned base image.