feat: pre-deploy scan visibility and pinned scanner version (#1378)

* feat: pre-deploy scan visibility and pinned scanner version

Pin managed Trivy installs and add an opt-in pre-deploy scan advisory so a
manual deploy can surface each image's latest scan before it runs.

- Managed Trivy now installs a pinned, known-good version by default for
  reproducible installs. Auto-update still tracks the latest release, and an
  explicit update always pulls the latest.
- Add an opt-in pre-deploy scan advisory: when enabled, deploying a stack from
  the editor first shows each image's latest cached scan severity for review.
  It is visibility only and never blocks; deploy enforcement is unchanged.
- Backend: pre_deploy_scan_advisory setting, PUT
  /security/pre-deploy-scan-advisory, a cache-only GET
  /security/stacks/:name/pre-deploy-summary, and a node-scoped
  getLatestVulnScanByDigestForNode lookup.
- Frontend: advisory toggle on the Security page scanner setup, and a
  PreDeployScanDialog wired into the editor deploy flow that fails open when the
  summary is unavailable.
- Docs: scanner configuration, version pinning, and the advisory.

* fix: harden pre-deploy advisory guard, toggle visibility, and installer busy state

Addresses review findings on the pre-deploy advisory.

- Block a second editor deploy during the async advisory window with a
  synchronous pending ref, cleared on cancel and in the deploy's finally, so a
  double-click can no longer start two deploys.
- Keep the pre-deploy advisory toggle visible to admins whenever the setting is
  on, so it can still be turned off after the scanner becomes unavailable.
- Resolve the managed Trivy version inside the install lock so the busy state and
  serialization cover the latest-version fetch and the managed-install check.

docs/features/vulnerability-scanning.mdx

@@ -21,13 +21,14 @@ The Trivy CLI must be available on the machine running Sencho. Trivy is not bund
 
 | Feature | Community | Admiral |
 |---------|:---------:|:-------:|
-| Install / update / uninstall Trivy from Settings | ✓ | ✓ |
+| Install / update / uninstall Trivy | ✓ | ✓ |
 | On-demand image vulnerability scanning | ✓ | ✓ |
 | Full scan (vulnerabilities + secrets) | ✓ | ✓ |
 | Compose file misconfiguration scanning | ✓ | ✓ |
 | Severity badges in the Resources Hub | ✓ | ✓ |
 | Scan results drawer with grouped tabs | ✓ | ✓ |
 | Post-deploy automated scanning | ✓ | ✓ |
+| Pre-deploy scan advisory on manual deploys | ✓ | ✓ |
 | Scan history sheet | ✓ | ✓ |
 | Scan comparison | ✓ | ✓ |
 | CVE suppressions | ✓ | ✓ |
@@ -127,6 +128,20 @@ The App Store deploy sheet has a **Security** section with a **Scan images for v
   <img src="/images/vulnerability-scanning/app-store-toggle.png" alt="App Store deploy sheet Security section with the auto-scan checkbox enabled" />
 </Frame>
 
+## Pre-deploy scan advisory
+
+The pre-deploy scan advisory is an opt-in review step for manual deploys. When it is on, deploying a stack from the editor (**Deploy** or **Save & deploy**) first opens a dialog listing each image in the stack with its latest scan severity, so you can review the security posture before the deploy runs.
+
+The advisory is visibility only: it never blocks a deploy. Anyone who can deploy reviews the breakdown and chooses **Deploy** to continue or **Cancel** to stop. Blocking a deploy on a severity threshold is a separate capability covered in [Deploy Enforcement](/features/deploy-enforcement).
+
+Enable it on the **Security** page → **Scanner setup** tab with the **Pre-deploy scan advisory** toggle (admin only). It is off by default.
+
+How it behaves:
+
+- The counts come from each image's most recent cached scan. An image that has not been scanned yet shows **not scanned**, and the dialog notes how long ago each scan ran.
+- It reads cached results only and never starts a new scan, so it does not slow the deploy. If the scan data cannot be read, the deploy proceeds normally.
+- It covers manual editor deploys (**Deploy** and **Save & deploy**). Automated paths (stack update, template deploy, Git source apply, scheduled runs) are already covered by [post-deploy automated scanning](#post-deploy-automated-scanning) and, where configured, deploy enforcement.
+
 ## Scheduled fleet scans
 
 You can run recurring scans of every image on a node through the standard [Scheduled Operations](/features/scheduled-operations) system. Create a scheduled task with action **Scan** and a cron expression. The scheduler iterates every image on the target node with a short delay between scans and records the result in the task's run history.

docs/operations/trivy-setup.mdx

@@ -36,6 +36,7 @@ Behind the scenes:
 - The Trivy binary is downloaded into Sencho's existing data volume at `/app/data/bin/trivy`. No host filesystem changes.
 - The vulnerability database cache defaults to `/app/data/trivy-cache` so it persists across container restarts.
 - Downloads are verified against the official Trivy checksum file before the binary is put in place.
+- By default the managed install pins to a known-good Trivy version, so a fresh install is reproducible rather than tracking whatever "latest" happens to be. Turn on **Auto-update Trivy** to track the newest release instead; an explicit **Update** always pulls the latest regardless of the toggle.
 - The installed version survives Sencho image upgrades because it lives on the mounted data volume.
 
 ### Updating the managed install