ci: build the Docker images in PR CI, then align Node to 24 LTS

[Abhash-Chakraborty]

Problem

Neither Dockerfile is built by any pull-request job. publish.yml is the only workflow that builds them, and it runs on release. Two consequences:

1. A broken Dockerfile is invisible until a release build. Nothing on a PR catches it.
2. CI and the shipped image drift apart silently. frontend-check pins node-version: 22 in ci.yml; frontend/Dockerfile separately pins node:22-alpine. They agree today by coincidence, not by any check. The same applies to backend/Dockerfile vs the python-version: "3.12" in backend-check.

This surfaced on #385, where Dependabot proposed node:26-alpine for the Dockerfile alone. I closed it — 26 is the Current line, not LTS — but I also couldn't move it to Node 24 (the Active LTS) in the same breath, because nothing would have verified the change.

Proposed

1. Add a docker-check job to ci.yml that builds frontend/Dockerfile and backend/Dockerfile on PRs that touch them. Build only — no push, no registry credentials. Gate it behind the existing detect-changes filters so it stays off for docs-only PRs, and use GitHub Actions cache so it isn't slow.
2. Once (1) is in place and green, bump node-version in frontend-check and the FROM in frontend/Dockerfile to 24 in a single commit, and add a comment at each site pointing at the other.
3. Consider asserting the two agree — a one-line grep step is enough and it fails loudly rather than drifting.

Notes

• Node 22 is Maintenance LTS through April 2027, so there's no urgency on the version itself. The missing coverage is the real issue.
• Node 24 is Active LTS until October 2026. Both pnpm 11 and Next 16 require Node >= 20, so 24 is comfortably supported.
• Step (1) is the part that's genuinely worth doing; (2) is a small follow-up once it exists.

Good task for someone who wants to work on CI. Step 1 is self-contained.