Add support for: https://jfrog.com/artifactory/

[ModeSevenIndustrialSolutions]

Problem

We need to test the workflows against JFrog Artifactory, and add full support for it. This needs to be a supported and tested platform, to aid migration away from the legacy/unsupported Nexus 2 platforms the Linux Foundation runs for some projects.

Scope updated 2026-09-17. Part of this has already landed. The remaining work is narrower and more specific than the original description suggests.

Already delivered

Commit 54d8767 ("Feat: Accept Artifactory registry addressing") taught merge.yaml how to address Artifactory:

• The registry inputs previously validated as host[:port], which matches how Nexus 3 addresses a repository (one port per repository) and rejects Artifactory's repository-path method (acme.jfrog.io/docker-snapshot) outright.
• The inputs now accept an optional repository path, and the lane separates two things it had conflated: a registry base, which prefixes image references and may carry a path, and a login endpoint, which is host[:port] and never does. docker login and crane receive the endpoint; docker tag and push receive the base.
• The release-file override check was corrected to strip the path before the port, so a legitimate override is no longer refused.
• registry_user was introduced as the preferred name for nexus_user, and the username charset now admits @ and + for Artifactory SaaS identities, which are commonly email addresses.

So the merge lane (Model B) can address an Artifactory instance today.

What remains

1. The release lane has no Artifactory support at all

build-test-release.yaml publishes only to GHCR and Docker Hub. Its entire registry surface is ghcr_publish, dockerhub_publish and image_namespace — there is no generic registry input, no registry base/login-endpoint distinction, and no credential loading.

A project releasing through Model A therefore cannot publish to Artifactory. Closing that means giving the release lane the same registry model the merge lane now has, which is a larger change than 54d8767 was, because the release lane also signs and attests by digest per registry.

2. Nothing has been tested against a real instance

This is the original ask and it is untouched. The addressing work was validated by reasoning and unit-level input validation, not against a live Artifactory.

Needed:

• an Artifactory instance (or a trial/SaaS tenant) to test against
• a push through the merge lane's snapshot and staging paths
• a promotion through the release path, confirming multi-architecture manifest lists survive the crane copy
• confirmation of which authentication shapes the instance accepts

This is the blocking dependency for the whole issue. Without a test target, neither the existing merge-lane support nor any new release-lane support can be called "supported and tested".

3. Registry capability matrix

README.md carries a registry capability matrix, referenced by sigstore_sign_required_registries, because cosign signature storage support varies by registry and cannot be inferred from the hostname. Artifactory's behaviour needs establishing and recording there before Model A can sign against it.

Suggested sequencing

1. Obtain a test target. Everything else is blocked on it.
2. Validate the existing merge-lane support against it, and record what the instance actually accepts.
3. Only then extend the release lane, informed by what step 2 finds rather than by the specification.