ci: require manual gated releases from main

docs/SECURITY_REPORT.md

@@ -132,15 +132,12 @@ change when the advisory database or selected base digest changes.
 The files in `deploy/` and `.gitea/workflows/` are a guarded delivery mechanism,
 not an approval to operate the current application on the public internet.
 
-Corrected 2026-09-21: an earlier version of this section described gates the
-workflow did not contain. The workflow now runs static validation, the
-integration suite against a live stack, and a blocking Trivy secret scan before
-publishing. The source preflight is advisory unless
-`ENFORCE_PRODUCTION_PREFLIGHT` is set, and image vulnerabilities are reported
-rather than enforced, because the current bases carry HIGH/CRITICAL findings
-with no upstream fix. Base images are still mutable tags, not digests.
-`PORTAINER.md` holds the authoritative table of what gates and what does not.
-It publishes both `latest` and the full commit SHA, then calls the Portainer
+Updated 2026-09-23: pushes to `main` run checks only. A manual workflow run on
+`main` requires the source preflight and a configured Portainer webhook before
+building. It scans built images before publication; CRITICAL findings block and
+HIGH findings are reported. The browser suites run in a required Compose Chrome
+container. `PORTAINER.md` holds the authoritative gate table. A permitted release
+publishes both `latest` and the full commit SHA, then calls the Portainer
 webhook. Application/provider secrets are created directly as versioned external
 Swarm secrets and never cross the workflow. Rollback selects the prior commit SHA
 in Portainer and does not roll back the database.