chore(ci): scan released images with Trivy - #8162

Adds a non-blocking Trivy scan of each image the release pipeline
publishes, reporting fixable CRITICAL and HIGH findings to code
scanning. Runs alongside the existing Snyk monitor step.

Both the action and the scanner binary are pinned, the latter because
the action's own default lags. Each image is scanned by the digest the
build just produced rather than by tag, so the report cannot describe
something other than what was released.

Nothing here can fail a release: the scan is continue-on-error with
exit-code 0, the upload is gated on the scan succeeding, and a failure
of either emits a warning annotation rather than passing silently.

Two details that are easy to get wrong. Results upload to refs/heads/main
because this workflow only runs on tag pushes and the alerts UI is scoped
to branches, so results left on refs/tags/* would land where nobody reads
them. And the category carries the release channel, because code scanning
reconciles per (ref, category) by closing any alert the newest analysis
omits, which would let a nightly close the alerts describing the stable
image users are running.

arm64 is published but deliberately not scanned. The OS packages are
pinned to the same versions for both arches and Debian advisories match
on version rather than arch, so its findings are amd64's.

Replaces the code scanning upload with a JSON report retained as a run
artifact, so nothing leaves the pipeline ahead of the secure portal
ingestion work that will consume these reports.

JSON rather than SARIF because it is Trivy's richest format, carrying
CVSS vectors per vendor, installed and fixed versions, layer attribution
and PURLs. `trivy convert` regenerates SARIF or a table from a stored
report offline, so nothing is foreclosed and no rescan is needed to
change format later.

Two consequences worth noting. The security-events permission is gone
from both jobs, and with the SARIF upload go the category and ref
semantics it needed, including the nightly channel suffix and the
assumption that release tags are cut from main.

Since nothing here touches job status, a report nobody opens would make
a release shipping twenty criticals look identical to a clean one. Each
job now writes its counts to the job summary and raises a warning
annotation when the count is non-zero.

The scanner pin moves out of Trivy's own TRIVY_* environment namespace,
where a workflow-level variable of that name would otherwise sit.

The artifact holds fixable findings only, since ignore-unfixed filters
the rest, and the comment says so rather than calling it a record of
everything the release shipped.

Addresses review feedback on #8162.

The scan, artifact upload and summary were duplicated between the core
and FIPS jobs, differing only in the image name. They move to
.github/actions/trivy-image-scan, alongside the existing
generate-openapi-spec action, so the scan configuration is defined once
and each job is left with a call and a guard.

The DB repository override was a regression. Trivy already defaults to
the GCR mirror followed by GHCR and falls back between them, but only
for temporary transport errors, which is what a rate limit is
(pkg/oci/artifact.go, shouldTryOtherRepo). Pointing the override at a
single ECR repository replaced that with one point of failure, and the
comment justifying it was wrong: GHCR is the fallback in this version,
not the default. ECR now sits in front of both rather than in place of
them.

The guard also missed the summary step, so a summary that failed left no
trace. Collapsing the three steps behind one composite call means any
failure inside it, scan, upload or summary alike, surfaces as that
step's outcome, and there is no longer a condition to keep in sync as
steps are added.

Reports are still kept in the pipeline rather than sent to code
scanning, pending the portal ingestion work.