build: run the image on a Wolfi runner

The dependency and build stages stay on node:22-trixie-slim, where pnpm
picks the glibc native packages. The runner moves to wolfi-base, pinned
by its index digest: glibc, about fifty packages, and every one of them
known to the image scan, Node and the PostgreSQL client included.

nodejs-22, tzdata and postgresql-18-client come from apk, so the pgclient
stage and its pin guard go. The builder writes its Node module ABI and
glibc version out and the runner refuses to build on another ABI or an
older glibc. Wolfi's npm is major 12 and runs no install scripts unless
package.json allows them, so the Prisma CLI install names the three
packages that have one, and the build checks that the schema engine file
is there before asking the CLI about it. npm is installed for that step
and removed in the same layer; the check that nothing is left asks a
fresh shell, whose command cache cannot remember the deleted binary.

.github/dependabot.yml

@@ -64,13 +64,6 @@ updates:
     schedule:
       interval: "weekly"
     open-pull-requests-limit: 3
-    ignore:
-      # The Dockerfile's `pgclient` stage carries pg_dump and pg_restore of
-      # the bundled database's major. A major bump there is part of the same
-      # migration decision as the database itself, and the runner's paths and
-      # version checks name major 18, so it arrives by hand, not as a PR.
-      - dependency-name: "postgres"
-        update-types: ["version-update:semver-major"]
   # The `docker` ecosystem above reads the Dockerfile only. The bundled
   # database lives in `docker-compose.yml`, which GitHub treats as its own
   # ecosystem, so without this block a new PostgreSQL minor release never

.github/workflows/security.yml

@@ -247,7 +247,7 @@ jobs:
 
       # Blocking since v1.15.20 — a HIGH/CRITICAL finding in the built
       # image fails the job. For a finding without an upstream fix
-      # (e.g. a base-image CVE Debian has not patched yet), add the CVE
+      # (e.g. a base-image CVE Wolfi has not patched yet), add the CVE
       # id to a `.trivyignore` file at the repository root — Trivy reads
       # it automatically — one CVE per line, each with a comment naming
       # the tracking issue and the re-check condition. Never suppress a