docs: an accuracy pass over SECURITY.md and the cosign identity

The severity rubric promised a rebuild and retag from a private branch for a Critical and a patch release in 30 days for a High. Neither is the mechanism. Fixes take the same public tag path as every other change, because a report here is typically a public advisory against a package the images already carry. A High is now triaged in 30 days and patched in that window where a fix exists; a finding with no upstream or vendor fix is recorded as detected with that reason, not dismissed.

The vulnerability-monitoring bullet claimed results surface in the project Security Dashboard. It now says findings are tracked in this project's vulnerability report, which makes no visibility claim. SAST is struck from it, the static-analysis bullet, and the site: the include stays, but no analyzer matches this tree, and pipeline 2828039374 runs secret_detection, dependency-scanning-profile-0 and container_scanning, with no SAST job.

A new ## Between releases section covers the gap .release-only-rules leaves. Nothing in this project's own .gitlab-ci.yml builds or scans an image outside a merge request that touches the build and a tag pipeline, so a scheduled security policy at .gitlab/security-policies/policy.yml in gitlab-com/public-sector/policies/public-sector-security-policy-project, linked at the gitlab-com/public-sector group and scoped to this project, runs container scanning against the six latest tags every Sunday at 06:00 UTC without rebuilding them. The pipelines that run against main are that policy's. A second policy resolves any finding those scans stop detecting, at every severity. Those scans read operating system packages, so Go module findings come from this project's own container scanning job rather than from the schedule. Its first run, pipeline 2823832592, ran six green container-scanning jobs, and the report now holds 356 resolved against 122 detected.

The published cosign command allowed refs/(heads/main|tags/v[0-9].*). Nothing signs from main: every image job carries .release-only-rules, whose arms require a merge request event or $CI_COMMIT_TAG, so no default-branch pipeline signs anything. Narrowed to refs/tags/v[0-9].* on all four surfaces that print it: SECURITY.md, README.md, the ## Get it footer tag-release.sh writes, and site/index.html. It holds for images released at v1.25.19 and later; a mirror taken before 2026-09-05 may hold a latest* digest signed at refs/heads/main.

The same correction lands on the site's "Every pipeline run, not only release tags, builds all six variants" and on README's fips140=only claim.

vale, shellcheck and check-versions.sh pass, with no new vale finding against origin/main. scripts/**/* is in the image jobs' changes: gate and tag-release.sh changed, so expect all six images to rebuild.