chore: publish image under images/ namespace

[felixboehm]

What

Switches the published container image for enopax/dex to the new org-wide package naming schema (proposed in enopax/enopax#15), while keeping the legacy path working during the transition.

The build workflow now publishes to both paths with the same digest and the same set of tags:

• Legacy (kept): ghcr.io/enopax/dex
• New (namespaced): ghcr.io/enopax/images/dex

Why

We are adopting a consistent package layout across the org:

• Container images: ghcr.io/enopax/images/<repo>
• Helm charts: ghcr.io/enopax/charts/<repo>

To avoid breaking existing consumers (manifests, deployments) that still pull ghcr.io/enopax/dex, this PR does not remove the old path. It dual-publishes so consumers can migrate at their own pace.

How

.github/workflows/artifacts.yaml previously computed a single image name as ghcr.io/${{ github.repository }} (which resolves to ghcr.io/enopax/dex). The Set image name step now emits:

• value — legacy path (unchanged behaviour for downstream outputs / attestation / release ref)
• new — namespaced path
• all — newline-separated list of both, fed to docker/metadata-action

docker/metadata-action accepts a multi-line images: input and generates the full tag matrix for every image, so docker/build-push-action pushes all tags to both repositories in a single build (same digest, same multi-arch manifest).

No literal ghcr.io/enopax/dex string exists in the repo (the name was always derived from github.repository), so no other in-repo references needed updating.

Cutover plan

1. This PR (dual-publish): images appear under both ghcr.io/enopax/dex and ghcr.io/enopax/images/dex. Consumers keep working unchanged.
2. Migrate consumers: update deployments/manifests that reference ghcr.io/enopax/dex to ghcr.io/enopax/images/dex (separate PRs in consumer repos — not done here). Known consumers: see notes below.
3. Deprecate legacy: once all consumers are migrated and a grace period has passed, a follow-up PR removes the legacy path from all (drop the legacy line), leaving only the namespaced path.

Notes / risks

• The new ghcr.io/enopax/images/dex package is created automatically on first push by the workflow GITHUB_TOKEN (which has packages: write). It will initially be private; an org admin may need to set its visibility/linkage to match the existing dex package.
• Set image ref / attestation still uses the legacy path as the canonical ref during the transition; the namespaced image receives the identical digest.
• Tag matrix and multi-arch (amd64/arm64) build behaviour is unchanged — only the set of target repositories grows.

Validation

• Workflow YAML parses; only .github/workflows/artifacts.yaml changed (24 insertions, 2 deletions).
• Searched the entire repo: no hardcoded ghcr.io/enopax/dex string exists. The only other ghcr.io references are an upstream example (examples/k8s/dex.yaml → ghcr.io/dexidp/dex:v2.32.0) and the registry login host, both intentionally left untouched.
• Known cross-repo consumers of ghcr.io/enopax/dex (to migrate in step 2, not changed here):
  • enopax/platform → docker-compose.yml, enopax.com_setup/opt/platform/docker-compose.prod.yml, enopax.com_setup/opt/deploy/deploy.sh (all pin ghcr.io/enopax/dex:2.45.1_file_store)