**What changed:** `dockerfiles/dockerfile-samgis-base` — `builder_global` stage repinned from `dhi.io/python:3.13-dev` to the exact same digest as the `runtime` stage (`dhi.io/python:3.13@sha256:a87c4bc7bbf75da7d5bb1816f2bdf7640c17eeb42d3ba84c5201827977da8de4`); its 3 shell-form `RUN` instructions converted to exec-form JSON arrays (using paths relative to `WORKDIR` rather than `${WORKDIR_ROOT}` substitution); final stage's `COPY --from=builder_global` model-weights source path updated from `/root/.samgis/...` to `/home/nonroot/.samgis/...`.

**Follow-up action:** when adding or modifying a multi-stage Dockerfile that builds artifacts (venvs, compiled binaries, anything with baked-in absolute paths) in one DHI (Docker Hardened Images) variant and copies them into another, first verify the two variants share the same Python/interpreter install location: `docker run --rm --network none <image> python3 -c "import sys; print(sys.executable, sys.prefix)"` for both. Only rely on cross-stage `COPY` of such artifacts if the paths match exactly.

**Do NOT:** assume `dhi.io/<lang>:<version>-dev` and `dhi.io/<lang>:<version>` (hardened, non-dev) are portability-compatible just because they're the same version or even the same release epoch (same `docker scout` provenance commit). Confirmed on 2026-07-25: `python:3.13-dev` installs Python at `/usr` (`/usr/bin/python3`), the hardened `python:3.13` installs it at `/opt/python` (`/opt/python/bin/python3`) — these are structurally different images, not just build-tools-vs-not.

**Trigger:** any time a build using a DHI `-dev` builder stage + hardened runtime stage starts failing with `ModuleNotFoundError` (or similar "the code that should be there isn't") in a runtime-stage smoke test, immediately after a base-image or Dockerfile change — check for this class of bug before assuming a dependency-resolution problem. Symptom signature: the missing package genuinely *was* installed successfully in the builder stage logs, but the runtime stage can't see it.

**Why:** a copied venv's `bin/python3` is a symlink baked with the builder's absolute interpreter path at creation time. If that path doesn't exist in the runtime image, `PATH` resolution silently falls through to the runtime's own separate interpreter — a real, working Python that has simply never heard of anything in the venv. No error is raised for the broken symlink itself; the failure surfaces several steps later as a missing-module error on whatever import happens to run first. Additionally, the hardened runtime variant defaults to a `nonroot` user (uid 65532, `HOME=/home/nonroot`) rather than root, which independently breaks any `~`-relative path assumptions carried over from a builder stage that ran as root.

**Verify:** `docker buildx build . -f dockerfiles/dockerfile-samgis-base ...` completes through the `runtime 7/7` smoke-test `RUN` step (`import rasterio; import onnxruntime; import fastapi; import uvicorn`) without error, and the final stage's model-weights `COPY --from=builder_global` step finds its source path.

**Rollback:** revert `builder_global`'s `FROM` line back to `dhi.io/python:3.13-dev` and its `RUN`/`COPY` instructions to their prior shell-form/paths — but this reintroduces the original bug; only do this if the pinned digest approach itself needs to be superseded by a different fix.