fix: honor provider build tags in Dockerfile.standalone

[mkousteris]

Problem

workable-1.3.1's image was built via .github/workflows/ci.yml's publish-artifacts job, which uses docker/build-push-action with file: Dockerfile.standalone — a plain docker build, not the Makefile-driven Dockerfile/Dockerfile.ubi path our CI never touches.

Dockerfile.standalone ran:

RUN go build -o external-secrets main.go

with no -tags flag at all.

Since upstream's v1.x provider-separation refactor (design/007-provider-versioning-strategy.md), every provider's registration is gated behind a Go build constraint — pkg/register/vault.go:

//go:build vault || all_providers
package register
...
func init() { esv1.Register(vault.NewProvider(), ...) }

(documented in AGENTS.md: "Makefile honors PROVIDER ?= all_providers and passes it as go build -tags"). A bare go build with no tags excludes every file in pkg/register, so nothing registers, and every store fails:

{"level":"error","logger":"controllers.ClusterSecretStore","msg":"unable to validate store","error":"could not get provider client: failed to find registered store backend for type: vault, name: <store>"}

Reproduced on workablestg9-eks after deploying this image — every ClusterSecretStore shows InvalidProviderConfig/Ready: False with exactly this error, despite valid Vault config.

Same root cause, same error shape as a real upstream bug: external-secrets/external-secrets#5807 (webhook provider missing from a make run dev build), fixed upstream in external-secrets/external-secrets#5851 — but that fix only touched Makefile/Tiltfile, never Dockerfile.standalone. This file's own header comment ("for building without external dependencies") confirms it's a real, intended build path — it just predates (or was missed by) the build-tag system and has carried this gap since.

Fix

Add ARG PROVIDER=all_providers (matching the Makefile's own default) and pass it through as -tags, so:

• A plain docker build -f Dockerfile.standalone . keeps working exactly as before (all providers included, matching current expectations).
• --build-arg PROVIDER=vault (or any other provider name/list) builds a slimmer binary when that's wanted.

Testing plan

• Build --build-arg PROVIDER=vault and confirm vault backend registers (controller starts, ClusterSecretStore/SecretStore reconcile to Ready)
• Build with no --build-arg (default) and confirm behavior matches current default (all providers present)
• Re-run workable-1.3.1 image build once merged, redeploy to workablestg9-eks, confirm ClusterSecretStore resources go Ready: True

Worth reporting upstream?

This gap exists in external-secrets/external-secrets's own Dockerfile.standalone too (unchanged from our fork, confirmed via diff at the same tag) — worth a matching upstream PR once verified here, since anyone building that file on v1.x+ hits the same issue.