Publish the container images through the org's shared pipeline

[Ilyes512]

Summary

• Replaces the hand-rolled images job with specsnl/github-actions' build-go-cli.yml / merge-go-cli.yml at 2.4.3 — one build per platform on a native runner, then a manifest merge. Login, buildx, the tag policy, OCI labels, provenance: false and a layer cache all come with it.
• Moves the debian image from the nested ghcr.io/specsnl/labelsync/debian to a -debian tag suffix on the one image name, which is how the shared pipeline publishes a CLI's base-image variants.
• Guards both stages on every pull request: built on a runner of their own architecture and actually run, through test/image.bats.
• Adds task lint:docker (hadolint, pinned in compose.yml) to task checkall and to CI, matching specs-cli.
• Rewrites the workflow assertions in release_test.go for the new shape and adds ci_test.go for the guard.

Notes for review

What stays in this repository is the three things only it can know: the stages to publish (binary, debian), the image name, and version-build-arg: LABELSYNC_VERSION. No version: input — the shared workflow defaults it to the tag without its leading v, which is what GoReleaser injects, so the image and the tarball cut from one tag agree about what they are.

2.4.3 is the floor, not just the newest tag. Up to 2.4.2 the shared merge job carried type=raw,event=workflow_dispatch,value=latest; event= is an attribute of type=ref, so metadata-action dropped it and the directive collapsed to an unconditional :latest on every run. Neither enable=false on the intended latest tag nor flavor: latest=false governs a second raw tag. Every labelsync tag so far is a v0.1.0-rc.N prerelease, so under 2.4.2 the next rc would have pointed :latest at a release candidate — the exact outcome the tag policy is meant to prevent. specs-cli hit it on v0.0.14-rc.2.

The debian rename is a breaking change to an address, deliberately taken now: ghcr.io/specsnl/labelsync/debian is frozen at 0.1.0-rc.4 and gets nothing further. Four release candidates is the whole exposure, and the suffix form is what node, python and postgres do.

The shared pipeline also emits type=ref,event=tag, so v1.2.3 is published as an alias onto the same digest as 1.2.3. Additive; :1.2.3 stays the form the docs and the CI recipe pin.

Native runners, not QEMU. The guard has to run what it builds, so each leg needs a runner of its own architecture. The Dockerfile's cross-compilation still holds and is still tested — it is what keeps a local --platform linux/arm64 build out of emulation.

task image:smoke runs the same bats file CI does, against both images: the injected version (built with a string no fallback can produce, so a renamed build arg is loud rather than silent), the uid, the CA bundle, and a bind-mounted config — valid, which gets as far as failing on the token, and invalid, which comes back with its error_kind.

hadolint had one finding on the existing tree — the base stage kept its apt lists. checkall grew a step, so AGENTS.md's description of the sequence moved with it.

Needs a human

• The four Image (...) jobs and Dockerfile lint are not in the branch ruleset's required checks, so they run but do not gate. Worth adding if that is wanted.
• Nothing to do for GHCR visibility: ghcr.io/specsnl/labelsync is already public, and the variant lands inside it.
• Expect No Docker tag has been generated in the build job logs. 2.4.3 leaves build-image with no tag directive on a tag push; it pushes by digest, so nothing is lost, and the manifest's org.opencontainers.image.version still comes from the merge job.

Verified locally

task checkall (including lint:docker), task image:smoke — 14 assertions across both images — task docs:build, and actionlint over both workflows. All green.