feat(docker-release): scan image for vulnerabilities with Trivy

[JSisques]

Summary

• Add an opt-in scan_image input (default false) to docker-release.yml and release-train.yml.
• When enabled: builds a linux/amd64-only, load: true copy of the image purely for scanning (the real multi-arch image stays push: false until this passes — multi-arch builds aren't docker load-able, so this is the only way to scan locally before publishing). Reuses the same buildx cache as the real build, so the extra build is cheap.
• Runs Trivy twice: once to always upload a full-severity SARIF report to Security → Code scanning (never fails), and once scoped to severity: CRITICAL, ignore-unfixed: true that actually fails the job. A CRITICAL with no upstream fix is reported but never blocks — otherwise a single unfixable CVE in a base image would block every future release.
• Runs on every channel (alpha/beta/stable), not just stable — an alpha/beta image still reaches real testers.
• Scanning happens before the version bump, git tag, and any push — a CRITICAL finding stops the release before anything is published.
• Adds security-events: write to both workflows' permissions (needed for the SARIF upload); documents in README that consumers enabling scan_image must grant it explicitly too.
• README: new "Docker image vulnerability scanning" section.

Consumed by gardenia-api, gardenia-web, nestjs-template, and cookidoo-mcp (companion PRs opting in on both their release-train and manual release workflows). nestjs-kit has no Docker release, so it's unaffected.

Test plan

• YAML validated locally (yaml.safe_load)
• Merge this first, then confirm a consumer's next release actually runs the scan and (if triggered) uploads a SARIF report

---

Generated by Claude Code