ci: publish through the orb's stock jobs with decoupled versions

[teemow]

What

The line's six images are published by the architect orb's push-to-registries job, one job per component, built from a fork-owned .circleci/Dockerfile that reproduces ko's image — ./cmd/<component> compiled with CGO_ENABLED=0 and -trimpath from the vendored modules, at /ko-app/<component> on the distroless base .ko.yaml pins, /ko-app on PATH, the binary the ENTRYPOINT — for linux/amd64 and linux/arm64: signed, with provenance and an SPDX SBOM, the index annotated io.giantswarm.upstream.version=<pin>. ko, the repo-owned version step and the version pipeline parameter are gone; the version is the orb's, from the git tags.

Versions are decoupled from upstream's (RFC "Semantic Versioning of Upstream Software"): a release is a tag vX.Y.Z (or vX.Y.Z-rc.N) and publishes X.Y.Z; 1.0.0 is the first, above the superseded 0.0.30-gs.N; a push to giantswarm publishes gitsemver's dev version. Every other branch runs the six builds with push: false, so a Dockerfile regression surfaces on the pull request.

scan runs Trivy from its image on the remote docker engine (one container per image, a shared database cache, .trivyignore copied in), scans the six images by tag and the agentgateway image report-only, records image-refs.txt and gates charts, which reads the version from .build_version.

The sync workflow derives the pin from the stable tags reachable from the branch that upstream also has: the line's own stable tags share the v* namespace and never count, and upstream main — rebased onto agent-substrate, no release tag among its ancestors — offers no merge-base to describe. FORK.md states the scheme ("Pin", "Re-pin", "Publishing", "Consumers").

The orb is giantswarm/architect@10.6.0 (the release that carries the build-args parameter). The agentgateway line's first decoupled release replaces v1.5.1-gs.4 in the chart default and the pipeline parameter before the merge.

How verified

• circleci config process --org gh/giantswarm .circleci/config.yml compiles; in the processed jobs every push job carries its COMPONENT=<component>, .build_version is persisted by the ateapi jobs only, and the validate jobs log in nowhere.
• docker buildx build --check on the Dockerfile reports no warnings; go list -mod=vendor resolves all six commands.
• ko's published 0.0.30-gs.5 binary read with go version -m: -trimpath=true, CGO_ENABLED=0, no ldflags, the VCS revision embedded — the Dockerfile builds the same way; the published image config (/ko-app/<name> ENTRYPOINT, /ko-app on PATH, the base's user) is reproduced per component.
• The pin derivation, run locally with upstream's tags present: v0.0.29 — also with a v1.0.0 tag on HEAD, where the previous derivation answered v1.0.0.
• This pull request's validate workflow builds all six images for both platforms without pushing.