fix(template): enable corepack in the builder stage, not just the runner

[chiro-hiro]

Problem

The generated Dockerfile emits RUN corepack enable only in the runner stage, but the build — yarn install / yarn build — runs in the builder stage. This works today purely by accident: the orochinetwork/ubuntu:node base image already ships yarn as a corepack shim, so the builder gets corepack behaviour it was never explicitly given.

This contradicts the documented contract in DOCKERFILE.md:

Enables corepack in both the builder and the runner (Strapi uses Yarn 4 berry; the base image ships Yarn 1).

If the base image ever stopped pre-shimming yarn, the Strapi (Yarn 4 berry) build would break with no corepack in the builder — and the runner-stage corepack enable is largely dead weight for the actual build.

Fix

Emit the corepack-enable layer in both stages:

• Dockerfile.template — add a {{builder_corepack_run}} placeholder in the builder stage, as root, before the USER switch (and before COPY . ., so the layer caches independently of application code).
• dockerfile.sh — substitute {{builder_corepack_run}} from the same generator used for the runner; refresh the now-stale comment.

nginx (which doesn't use corepack) is unaffected — neither stage gets the layer.

Verification

• dockerfile.sh dry-run: corepack enable now appears in builder and runner for node/next/strapi, and in neither for nginx.
• In the builder, RUN corepack enable is emitted before WORKDIR/COPY/USER → runs as root.
• Real docker build of a node consumer: corepack enable runs as root in the builder ([builder] RUN corepack enable) before the USER switch and the build succeeds.
• shellcheck -e SC1091 clean, bash -n clean, checksum.sha256 regenerated & verified, full dry-run smoke + strapi contract pass.

Note on overlap with #58

This branch is cut from main, which is currently red from the #57 merge (a false-positive shellcheck SC2016 + a stale checksum). To keep this PR green on its own, it carries the same one-line SC2016 silence as #58 and a freshly regenerated checksum.sha256. The two PRs therefore overlap on dockerfile.sh/checksum.sha256; whichever merges second needs a trivial rebase + ./generate-checksums.sh. Functionally independent of #58.