Dockerfile builder stage pins node:23.11.1 — a non-LTS line, EOL since 2025-06-01

### Summary

The builder stage of this repo's `Dockerfile` pins a Node line that has been out of support for over a year:

```dockerfile
# ---------- builder ----------
FROM node:23.11.1-alpine3.21 AS builder
```

Verified against [`nodejs/Release`'s `schedule.json`](https://raw.githubusercontent.com/nodejs/Release/main/schedule.json):

| line | start | lts | maintenance | end of life |
|---|---|---|---|---|
| v23 | 2024-10-16 | **never** | 2025-04-01 | **2025-06-01** |
| v22 Jod | 2024-04-23 | 2024-10-29 | 2025-10-21 | 2027-04-30 |
| v24 Krypton | 2025-05-06 | 2025-10-28 | 2026-10-20 | 2028-04-30 |

v23 is an **odd-numbered line — it was never LTS**, and it went EOL on 2025-06-01. It receives no security patches, including for the bundled OpenSSL and undici.

### Why this matters more than it looks

This is not a peripheral image. `gofr-dev/gofr`'s `docs/Dockerfile` does:

```dockerfile
FROM ghcr.io/gofr-dev/website:${WEBSITE_TAG} AS builder
...
RUN npm install
RUN npm run build
```

So this builder stage is the runtime that actually performs `next build` for **production `gofr.dev`**, on both the prod and stage deploy paths.

For context, [gofr-dev/gofr#3870](https://github.com/gofr-dev/gofr/issues/3870) flagged that those deploy workflows ran `setup-node` on Node 18 (EOL 2025-04-30), fixed in [gofr-dev/gofr#3871](https://github.com/gofr-dev/gofr/pull/3871). But `setup-node` there governs only the runner-side `yarn install` / `yarn refresh-data` steps — it cannot reach this pin. The build itself is on v23, which is *staler* than the Node 18 that issue was about, and the fix has to land here.

### Suggested fix

```dockerfile
FROM node:24-alpine AS builder
```

24.x is the current Active LTS (EOL 2028-04-30). 22.x also works and is supported, but has been in maintenance since 2025-10-21, so it buys ~12 months less.

### Verification already done

`yarn install --frozen-lockfile` was run against this repo's current `package.json` + `yarn.lock` in a throwaway `node:24-alpine` container — Node v24.19.0, Yarn 1.22.22:

- exit **0**
- lockfile satisfied, no resolution drift
- no new warnings beyond the pre-existing unmet-peer-dependency set (`@algolia/autocomplete-*`, `autoprefixer`/`postcss`, `ts-api-utils`)

So the dependency install is known-good on 24. What is *not* yet verified is the full `next build` (Next.js 13.4.16) plus `sharp@^0.32.6` on Node 24 — `sharp` ships native binaries and is the most likely thing to need a bump alongside this. Worth building the image locally before merging.

Note the `alpine3.21` suffix can simply be dropped, letting the tag track the current Alpine base for that Node line, unless it was pinned deliberately.

Start with the builder stage in Dockerfile and review the current Node image pin and Alpine suffix. Run the full image build, including next build, after installing dependencies; check whether sharp@^0.32.6 works on the selected supported Node line. Done means the production image builds successfully with a supported Node base and no dependency drift.

Written by the indexing model from the issue text.