chore(docker): build on Node 24 LTS instead of EOL, never-LTS Node 23

[aryanmehrotra]

What

The builder stage pinned node:23.11.1-alpine3.21. This moves it to node:24.19.0-alpine3.24.

Why

23 is an odd-numbered Node release. Those never become LTS, and 23 reached end-of-life on 2025-06-01 — so the Node producing every deployed artifact has been receiving no security patches for over a year. Against nodejs/Release/schedule.json:

	lts	maintenance	end	today
v23	never	-	2025-06-01	EOL
v22	2024-10-29	2025-10-21	2027-04-30	maintenance
v24	2025-10-28	2026-10-20	2028-04-30	active LTS

24 rather than 26, which does not become LTS until 2026-10-28.

The patch + Alpine-minor pinning is kept deliberately, matching what was there before, so an upstream rebuild cannot change the toolchain under a release.

How this surfaced

Reviewing gofr-dev/gofr#3871, which moves the two website deploy workflows off EOL Node 18. That PR is correct and correctly scoped — its comment notes that the runner's Node governs only yarn install and yarn refresh-data, because next build runs inside this image against its own pin. Which is exactly the point: the runner-side Node was three years EOL, and the one that actually builds the site was a year EOL and never supported to begin with. The two need fixing separately, and this is the second half.

Verification

Not just a build — the image was run and the site actually served.

	node:23.11.1-alpine3.21	node:24.19.0-alpine3.24
docker build	ok	ok
static export	230 files	230 files
/	-	200
/docs	-	200
/team	-	200
/changelog	-	200
/faq	-	200
/comparison	-	200

Both pins were built from the same tree; the export file count is identical, so this is not changing what ships.

Separately confirmed on the runner side, against this repo at main: yarn install --frozen-lockfile and yarn refresh-data both succeed on Node 24 (138 team members, 21015 stars, 50 releases fetched), and the data they generate feeds this image build cleanly. sharp@0.32.6 — the one native dependency, and the usual casualty of a Node major bump — installs without falling back to a source build.

Noticed while verifying, not fixed here

yarn refresh-data run against a standalone checkout of this repo rewrites src/data/doc-mtimes.json from 56 entries to 0. generate-doc-mtimes.mjs walks src/app/docs and friends, whose .md content is overlaid from the framework repo after that stage, so there is nothing to timestamp at the point it runs. Node 18 produces the same empty result, so it is not version-related and it is not new.

Worth someone confirming whether the deploy job hits this too — if it does, the "Last updated" bylines and dateModified JSON-LD are being blanked on every deploy. Filing as an observation rather than guessing at the fix, since it depends on where the overlay lands relative to refresh-data.