ci: publish images from every green push to main

The release job enforced the production source preflight, which blocks while
the payment and messaging adapters are fake. They still are, by design, so
since 2026-09-23 no release could succeed and production kept running older
images while main moved on.

Pushes to main that pass validation, the integration suite and the scans now
build, scan and publish the images. Nothing is deployed automatically:
production changes when the stack is pulled and redeployed in Portainer. A
manual run also calls the Portainer webhook when one is configured. The
preflight stays in the scan job, advisory unless ENFORCE_PRODUCTION_PREFLIGHT
is true, in which case a blocked preflight stops publishing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/PORTAINER.md

@@ -17,9 +17,11 @@ Cloudflare R2, so MinIO is not part of this stack.
 
 The single workflow is `.gitea/workflows/deploy.yml`. Every push and pull request
 runs static validation, the integration suite against a real stack, and a secret
-scan. A push to `main` does not publish or deploy. A manual workflow run on
-`main` repeats those checks, builds and scans the images, then publishes both
-`latest` and the full commit SHA and calls Portainer.
+scan. When all of them pass on a push to `main`, the images are built, scanned
+and published as both `latest` and the full commit SHA. Nothing is deployed:
+production changes when someone pulls and redeploys the stack in Portainer. A
+manual workflow run on `main` does the same and also calls the Portainer
+webhook, if `PORTAINER_WEBHOOK` is configured.
 
 What actually gates a deployment:
 
@@ -29,16 +31,18 @@ What actually gates a deployment:
 | Integration suite on a live stack (smoke, workflow, security, scanning, retention, runtime) | yes |
 | Browser suites | yes; Chrome runs in the Compose test container |
 | Trivy secret scan (HIGH/CRITICAL) | yes |
-| Source preflight (`deploy/production_preflight.py --source-only`) | yes for manual release; advisory on pushes unless `ENFORCE_PRODUCTION_PREFLIGHT` is `true` |
+| Source preflight (`deploy/production_preflight.py --source-only`) | advisory unless `ENFORCE_PRODUCTION_PREFLIGHT` is `true`, which blocks publishing |
 | Trivy image vulnerabilities, CRITICAL | yes |
 | Trivy image vulnerabilities, HIGH | no — reported before publication |
-| Configured Portainer webhook | yes for manual release |
+| Configured Portainer webhook | no — called on manual runs when present; otherwise redeploy in Portainer |
 
-The source preflight refuses a release while the payment and messaging adapters
-are fake. It remains advisory on push checks so development can continue, but a
-manual release is blocked until those adapters are replaced. Set the repository
-variable `ENFORCE_PRODUCTION_PREFLIGHT` to `true` when all pushes should also
-fail on those blockers. Before a manual release, run the full configuration
+The source preflight reports while the payment and messaging adapters are
+fake. From 2026-09-23 it was enforced on every manual release, and since the
+adapters are still fake no release could succeed: production kept running
+older images while `main` moved on. It is now advisory everywhere. Set the
+repository variable `ENFORCE_PRODUCTION_PREFLIGHT` to `true` once the real
+adapters are in place, and a blocked preflight then stops images from being
+published. Before a manual release, run the full configuration
 preflight below against the actual Portainer values; CI checks source only.
 
 CRITICAL image findings block. Both images carry none: the bases are pinned by

docs/ROADMAP.md

@@ -713,8 +713,11 @@ print-file evidence still need correction before this item can close.
 - `[ ]` 5.13 — Define production recovery: scheduled encrypted offsite database
   and object backups, a consistent snapshot boundary, Swarm data placement and
   a restore rehearsal that opens every required live order file.
-- `[ ]` 5.14 — Promote and verify one immutable release. Normal `main` pushes
-  now run checks only; manual dispatch requires source preflight and a configured
+- `[ ]` 5.14 — Promote and verify one immutable release. **2026-09-24:** green
+  pushes to `main` now publish images and Portainer's pull-and-redeploy is the
+  release gate; the source preflight is advisory unless enforced by variable,
+  because enforcing it while the adapters are fake made every release fail.
+  Previously: normal `main` pushes ran checks only; manual dispatch required source preflight and a configured
   webhook, and scans images before publishing. Still make the full preflight
   validate the active stack, deploy the tested immutable image references, test
   clean install and upgrade, check application readiness after Portainer