Restore Trivy gate to exit-code: "1" in gke-images workflow

[dantaik]

Context

The Trivy scan steps in .github/workflows/gke-images.yml are currently report-only (exit-code: "0") so CVE findings upload SARIF to GitHub Security but don't fail the build. This was a deliberate, documented softening (commit 76eb6f9, PR #162) so we could ship v2.2.0 — the gate was blocking every release due to upstream CVE-DB growth (litestream Go stdlib, devDep CVEs) on code that was identical to what was running in production.

The softening is intended to be temporary. This issue tracks restoring the blocking gate.

Prerequisites

This issue is gated on:

• Upgrade litestream 0.3.13 → 0.5.x in hub + watchtower Dockerfiles #163 — Upgrade litestream 0.3.13 → 0.5.x. Removes ~56 of the 175 HIGH/CRITICAL findings on v2.2.0.
• Restructure hub + watchtower Dockerfile runtime stage to ship prod-only deps #164 — Restructure Dockerfile runtime stage to ship prod-only deps. Removes ~6 more (devDeps that shouldn't be in runtime).

After both land, re-run a build and verify the SARIF in GitHub Security drops below the gate's tolerance.

Acceptance criteria

• Confirm a fresh Trivy scan against the post-Upgrade litestream 0.3.13 → 0.5.x in hub + watchtower Dockerfiles #163-Restructure hub + watchtower Dockerfile runtime stage to ship prod-only deps #164 hub + watchtower images reports zero HIGH/CRITICAL findings with ignore-unfixed: true.
• If anything is left, allowlist it explicitly via .trivyignore with a comment justifying each entry (vendor-non-applicable, scheduled upgrade in <30 days, etc.). Don't silently lower thresholds.
• In .github/workflows/gke-images.yml, restore exit-code: "1" on both Trivy steps (lines ~170 and ~188 at the time of writing; check the file for the current line numbers).
• Remove the temporary explainer comment that was added above the Trivy scan - hub step in PR ci(gke-images): make Trivy scan report-only #162.
• Push a tag (or trigger a build) and verify Trivy passes on the new images, then verify it would have failed on the v2.2.0 image (sanity check the gate still works).

Why this matters

A blocking SCA gate is one of our supply-chain controls. Leaving it report-only means a real CVE introduction in app code wouldn't auto-block a deploy.

Pointers

• Workflow: .github/workflows/gke-images.yml:156-191
• Softening commit: 76eb6f9 (PR ci(gke-images): make Trivy scan report-only #162). Read the commit message — it documents the policy.
• Trivy SARIF baseline for v2.2.0: GitHub Security tab → trivy-hub and trivy-watchtower categories.

Severity

Medium — supply-chain control. Not currently exploitable, but the SCA gate is a defense-in-depth measure that should be restored as soon as the prerequisite CVE cleanup lands.