fix: upgrade OS packages in runtime stage to pick up Alpine security patches

[DeepDiver1975]

Context

The oCIS runtime image (v8/Dockerfile.multiarch) installed packages with apk add --no-cache but never ran apk upgrade. Already-present base-image packages were therefore patched only when the Alpine base tag was bumped (via Renovate, e.g. alpine:3.24.0 → 3.24.1).

Between base-tag bumps the shipped image could carry OS packages with known CVEs even though fixed versions were already available in the Alpine repository — surfacing as Trivy HIGH/CRITICAL findings that could only be resolved by waiting for a base-tag bump.

Change

Add apk upgrade --no-cache to the runtime stage only, so the final image picks up Alpine security patches at build time. The two builder stages are throwaway (their layers are discarded) and do not affect the shipped image's CVE surface, so they are left unchanged. The upgrade and install share a single RUN layer / package-index refresh.

Trade-off

apk upgrade slightly reduces build reproducibility — builds on different days may pull different patch versions. This is intended (the point is to track upstream security patches) and matches the rolling/daily-build model already used by this repo.

Verification

• ✅ Image builds successfully for linux/amd64
• ✅ apk upgrade --simulate in the built image shows nothing pending — packages fully patched at build time
• ✅ Binary reports version 8.0.1
• ✅ CI-equivalent smoke test (ocis init || true; exec ocis server) — status.php returns "productversion": "8.0.1"

🤖 Generated with Claude Code

[DeepDiver1975]

🤖 Automated review by Claude Code review agent.

Summary: Adds apk upgrade --no-cache to the runtime stage of v8/Dockerfile.multiarch so the shipped image picks up Alpine security patches at build time. The change is correct and idiomatic; the rationale in the PR body is sound.

Correctness — looks good:

• v8/Dockerfile.multiarch:64 — the upgrade is added to the runtime stage (the final FROM alpine:3.24.1 / stage-2), exactly where the CVE surface of the shipped image lives. Builder stages are correctly left untouched (their layers are discarded).
• The upgrade is chained into the same RUN as apk add (apk upgrade --no-cache && apk add --no-cache ... && echo ...), sharing one package-index refresh and one layer. This matches the existing single-RUN convention used elsewhere in this Dockerfile.

Risk assessment — low:

• The base image is pinned by digest (alpine:3.24.1@sha256:bec4ccd...), and apk upgrade against the stable 3.24 branch only serves point/security updates within that release — so there is no risk of an unintended major-version bump breaking the image. --no-cache keeps the layer clean.
• The reduced build reproducibility is real but intentional and explicitly acknowledged; it matches this repo's rolling/daily-build model. No objection.
• README.md:72 is updated to document the behavior — accurate and helpful.

CI status: The build / build (amd64) and (arm64) jobs are failing, but the failure is unrelated to this change. The error is in the node-builder stage: ERR_PNPM_NO_PKG_MANIFEST No package.json found in /build/services/idp at RUN pnpm install --frozen-lockfile. The runtime-stage step that this PR modifies (apk upgrade --no-cache && apk add ..., step #10) ran successfully before the node-builder step failed. The parallel build (8.0.4) and build (8.1.0-rc.1) matrix jobs passed on both amd64 and arm64, confirming the Dockerfile diff itself builds. This looks like a pre-existing upstream/idp clone-manifest issue on the rolling master build, not a regression introduced here.

Verdict: The change itself is correct and safe to merge. Recommend confirming the unrelated node-builder / idp pnpm install failure on the rolling build is a known transient/upstream issue before merging, since the required build check is currently red.