ci!: migrate docker config to dockers_v2

[nikpivkin]

Description

dockers_v2 is production-ready in GoReleaser v2.16.0. It replaces the separate dockers + docker_manifests blocks with a single entry that uses docker buildx for native multi-arch builds.

Breaking change (architecture-specific image tags): The old dockers approach published separate per-arch images with name suffixes (e.g. trivy:0.x.y-amd64, trivy:0.x.y-arm64) before merging them into a manifest list via docker_manifests. With dockers_v2 / docker buildx, the multi-arch manifest is built directly — intermediate per-arch tagged images are no longer pushed. If any consumers pin to an architecture-specific suffix tag, they will need to switch to the plain tag and let the registry resolve the correct arch.

Changes

goreleaser.yml

• Replace 4 dockers entries + 6 docker_manifests entries with a single dockers_v2 block with platforms, images, and annotations
• OCI annotations moved to annotations field (previously in labels)

Dockerfile

• COPY ${TARGETPLATFORM}/trivy — dockers_v2 places pre-built binaries into platform-specific subdirectories (linux/amd64/, linux/arm64/, etc.)
• Default TARGETPLATFORM=. preserves local build support

Testing

Test run: https://github.com/nikpivkin/trivy/actions/runs/26814550463/job/79052883502

• Multi-arch manifest (amd64, arm64, s390x, ppc64le) ✓
• OCI annotations on manifest index ✓
• docker run --rm ghcr.io/nikpivkin/trivy:0.109.0 version → Version: 0.109.0 ✓

Notes on dockers_v2

dockers_v2 is currently a provisional name in GoReleaser v2. It is planned to replace both dockers and docker_manifests as the single canonical block in GoReleaser v3 (no ETA). When this project upgrades to GoReleaser v3, a further migration step will be required (likely a simple rename of the block key). This PR deliberately adopts dockers_v2 now so that the v3 migration is a trivial diff rather than a full rebuild of the config.

Related PRs

• ci: bump GoReleaser to v2.16.0 #10774

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).