feat(events-processor): harden the production Dockerfile onto the Wolfi bases

[IxDay]

Draft. I opened this before noticing events-processor/Dockerfile.staging already exists on main. Retargeted as the production follow-up; it should land only after the staging bake (getlago/lago-deploy#3522) passes. See "Relationship to Dockerfile.staging" below.

What this is for

Dockerfile.staging hardened the staging build path and deliberately left ./Dockerfile alone. That means the production events-processor — what prod-us-1 and prod-eu-1 actually run — is still debian:13-slim running as root. This PR closes that.

stage	before	after
rust	rust:1.85	ghcr.io/getlago/events-processor-build
go	golang:1.25	ghcr.io/getlago/events-processor-build
runtime	debian:13-slim + apt-get install ca-certificates	ghcr.io/getlago/events-processor-base

Result, built from this branch (lago-events-processor:sha-2e8f228): 30.6MB vs 74.7MB, and the image config carries User: 65532 instead of root.

Relationship to Dockerfile.staging

The two would be near-duplicates, which is how they drift. Once this lands, Dockerfile.staging and lago-deploy's build-events-processor-staging-image.yml should collapse back onto the single production Dockerfile. I have deliberately not done that here — deleting the staging path before its bake completes would remove the safety net this whole sequence exists to provide. Happy to fold it into this PR or leave it as a follow-up, whichever you prefer.

Where it differs from Dockerfile.staging

Not just a copy — three fixes worth keeping whichever file survives:

1. lago-expression pinned by commit, not tag. Dockerfile.staging does git clone --tags … + git checkout v0.2.0: a ref that can be repointed, and it drags every branch and tag down to do it. This fetches the single pinned commit a22ab02 — 62 objects.
2. Base images pinned to a lago-packages commit sha, not :latest. A base bump becomes a reviewable diff instead of a silent change under a floating tag.
3. go mod verify alongside go mod download.

Two things worth a reviewer's attention

CGO stays enabled — this cannot be a static build. expression-go binds to libexpression_go.so via #cgo LDFLAGS: -lexpression_go. The .so is staged onto the linker path in the go stage as well as the runtime stage, because -lexpression_go resolves at link time, not just at load time. That is why the runtime base carries glibc and libgcc.

Pre-existing version skew, preserved. go.mod requires expression-go v0.1.4 while the Dockerfile builds the cdylib from v0.2.0. That predates this PR and is left exactly as-is — flagging it because it is load-bearing and easy to "tidy" into a breakage.

Verification

• CI branch build green: run 36736148427, multi-arch amd64 + arm64
• image config pulled from ECR: User: 65532, Entrypoint: /app/event_processors, WorkingDir: /app
• workspace builds --package expression-go clean on rust 1.98 — what Wolfi's rust provide resolves to, vs the 1.85 pinned before, which was the main toolchain risk
• go mod download && go mod verify → all modules verified