UID2-7390: add optional image_ref to shared vuln-scan notify workflow

[swibi-ttd]

What

Adds an optional image_ref input to shared-vulnerability-scan-failure-notify.yaml. When set, the workflow skips the JDK / mvn package / docker build steps and scans that already-published image reference directly. When empty (the default), behaviour is unchanged.

Why

The scheduled notify workflow had two modes:

• fs — scans repo files (npm/maven manifests). Blind to the contents of a base image (e.g. the Java JARs inside a Keycloak base image).
• image — mvn package → docker build of a single default Dockerfile → scan the freshly-built image. Assumes a Maven project with one Dockerfile, and only ever scans a just-built image.

Neither can re-scan an already-released image over time for CVEs disclosed after it was built. That's the gap behind UID2-7390 (the Self-Serve Portal's published Keycloak image accumulated 14 HIGH auth CVEs — incl. CVE-2026-4282 — that no scheduled scan ever surfaced, because the portal is a Node app with three differently-named Dockerfiles and runs the notify in fs mode).

How it stays backward-compatible

image_ref defaults to ''. The four build-from-source steps are now gated on inputs.scan_type == 'image' && inputs.image_ref == '', and the scan step resolves image_ref to the supplied value or the locally-built tag:

image_ref: ${{ inputs.image_ref != '' && inputs.image_ref || steps.meta.outputs.tags }}

The 7 repos that currently call this workflow in image mode (uid2-admin, uid2-core, uid2-e2e, uid2-operator, uid2-optout, uid2-snowflake, uid2-validator) pass no image_ref, so they run the exact same build-from-source path as today. No changes required in those repos.

Notes

• The supplied image must be pullable without auth, or the caller must log in to the registry before invoking the workflow (documented in the input description). The first consumer (uid2-self-serve-portal, public GHCR images) needs no login.
• Trivy action remains SHA-pinned (unchanged) — no floating tags, per the recent trivy-action supply-chain compromise.
• Also unblocks UID2-7353 (recurring scan of pinned EKS addon images).

Consumer PR

uid2-self-serve-portal will call this with scan_type: image + image_ref for its three published images (separate PR). Requires v3 to be re-tagged to this commit after merge.

🤖 Generated with Claude Code

[swibi-ttd]

Closing in favor of a portal-local build-then-scan job (UID2-7390). For the Self-Serve Portal we want to build the Keycloak/migration images fresh from their Dockerfiles each scheduled run and scan the freshly-built image — consistent with how the Java repos' image-mode scan works (mvn package → docker build → scan), rather than scanning a mutable published :latest tag.

The image_ref capability added here (scan an already-published, un-buildable image) is still the right tool for scanning AWS-published EKS addon images — moving it to UID2-7353. Branch swi-UID2-7390-image-scan-notify left intact for that revival.