fix: pin CLI image dependencies and OTel exporters

[plural-copilot]

Summary

• Pin both Go/Alpine stages to the verified multi-platform golang@sha256:3889b425f035be855a72fb4755265311293b6d414521f0a519d819df32222d83 index (verified linux/amd64 and linux/arm64 manifests).
• Replace apk update and unpinned installation with the v3.24/main source, explicit pins for git, build-base, their complete observed closure, and libssl3/libcrypto3=3.5.8-r0; assert the two required exact package versions during the image build.
• Add narrow direct MVS floors for OTLP gRPC and HTTP trace exporters at v1.45.0, then run go mod tidy with Go 1.26.6.

Fixes PROD-5210

Evidence

• Signed v3.24/main APKINDEX inspection found libssl3=3.5.8-r0 and libcrypto3=3.5.8-r0 for x86_64 and aarch64; the complete git/build-base closure versions matched across both indexes. The exact pinned APK install/assertions completed for amd64.
• go list -m all resolves both exporter modules to v1.45.0; go mod graph has root edges at v1.45.0.
• git diff --check passed.
• make test and make lint were attempted but fail before running because the host has no go (both exit 127); lint also lacks golangci-lint.
• Full final-image validation was attempted but is limited locally: Docker lacks buildx, arm64 execution returns Exec format error, and the bounded legacy amd64 build remained in go mod download. CI's existing native Buildx matrix remains unchanged and should validate both final platforms and plural --help.

Artifact and risk

CI publishes ghcr.io/pluralsh/plural-cli; this PR does not publish or change a pluralsh/plural-cli artifact/tag despite the ticket wording. Residual risk is limited to local final-image validation and continued availability of explicitly pinned v3.24 artifacts; pins and build-time assertions fail rather than silently selecting newer packages. Git and build-base are intentionally retained to avoid gratuitous runtime behavior changes.

[plural-copilot]

This PR was generated by the codex Plural Agent Runtime. Here's some useful information you might want to know to evaluate the ai's perfomance:

Name	Details
💬 Prompt	Implement PROD-5210 in one focused PR. You have an earlier analysis: production image is Dockerfile, published multi-arch by .github/workflows/ci.yaml to ghcr.io/pluralsh/plural-cli; current stages use golang:1.26.6-alpine3.24 and an unpinned apk update && apk add --no-cache git build-base; Go MVS currently leaves OTLP trace exporter modules at 1.43.0. The authoritative requirements are non-negotiable....
🔗 Run history	View run history

[linear]

PROD-5210

[greptile-apps]

Confidence Score: 4/5

The PR should not merge until exact APK revisions are backed by an immutable or durable package source so future image builds remain reproducible.

Findings

1.  Mutable repository breaks pins ▶

Summary

Pins the Go/Alpine builder and runtime stages by digest, installs an exact Alpine package closure, and raises the OTLP trace exporters and related OpenTelemetry modules.

• Both Docker stages now use the same multi-platform image digest.
• The final image installs exact versions of Git, build tooling, OpenSSL, and their observed dependencies.
• OTLP gRPC and HTTP trace exporters receive direct minimum-version requirements at v1.45.0.
• The exact APK revisions remain dependent on a mutable repository, making future cache-miss image rebuilds fragile.

_{Reviews (1) · Last reviewed commit: "fix: pin CLI image dependencies and OTel..."}

[greptile-apps]

Mutable repository breaks pins

The exact APK versions are resolved from the mutable v3.24/main repository. When Alpine publishes newer revisions and removes these revisions from its APK index, a cache-miss rebuild will fail at apk add, blocking the amd64 and arm64 image builds and subsequent CLI image publication. Use a durable snapshot or preserved APK artifacts if historical rebuilds must remain reproducible.