Optimize Trivy scanning by reusing container scan state

[cdcavell]

Summary

Optimizes the container release workflow so Trivy no longer performs three independent scans of the same saved container image archive.

The workflow now performs a single Trivy scan against artifacts/container-image.tar and reuses that scan result to produce the existing security and release evidence.

Changes

• Perform one Trivy scan of the saved release image archive.
• Store the reusable scan result in JSON format.
• Generate the SARIF vulnerability report from that scan result.
• Generate the SPDX JSON SBOM from the same scan result.
• Evaluate the same result for the existing HIGH,CRITICAL vulnerability release gate.
• Enable reuse of the Trivy cache within the workflow.
• Preserve normal vulnerability database update behavior so cached data is not treated as permanently fresh.

Security behavior preserved

This change does not weaken the container release security controls.

The workflow continues to:

• scan the exact image archive that is subsequently published;
• upload SARIF results to GitHub Code Scanning;
• generate SPDX SBOM release evidence;
• fail closed when HIGH or CRITICAL vulnerabilities exceed the existing threshold;
• retain the scanned image archive as the artifact passed into the publish job.

Benefit

Previously, the same image archive could trigger repeated Trivy setup, database access, package analysis, and vulnerability evaluation.

Reusing a single scan result reduces duplicate CPU and network work while ensuring SARIF, SBOM, and vulnerability-gate decisions are derived from the same scan state.

Validation

• git apply --check
• git diff --check
• reviewed workflow data flow to confirm all security outputs remain tied to the same saved container image archive

Runtime and network improvement can be measured against the previous workflow during the next container release execution.

Closes #533