feat: add dedicated Security page and policy-pack foundation (#1362)

* feat: add dedicated Security page and policy-pack foundation

Bring vulnerability scanning, scan history, suppressions, Compose risks,
secrets, policy packs, and scanner setup into one node-scoped Security
command center instead of scattering them across Resources and Settings.

- New top-level Security view with Overview, Images, Compose risks,
  Secrets, Policies, Suppressions, History, and Scanner setup tabs
  (status masthead + signal rail; controlled tabs with deep-link support).
- Backend: GET /security/overview rollup and GET /security/policy-packs
  static catalog (auth-only, Community). DatabaseService gains an uncapped
  scan-status count and a node-eligible block-policy count, and
  getImageScanSummaries now projects secret and misconfig counts.
- Reuse existing surfaces: the scan-history sheet, the control-governed
  suppression and acknowledgement panels, and the scan-detail sheet (now
  with an initial-tab prop so it opens on the matching finding type).
- Extract a shared SeverityBadge (from Resources) and a TrivyManager
  (from Settings) so both surfaces render identical controls.
- Resources "Scan history" now links into the Security page History tab.
- Docs for the new Security surface and tests for the new endpoints,
  helpers, nav wiring, and tabs.

* refactor: consolidate scanner and policy management onto the Security page

Remove the Settings "Vulnerability Scanning" section now that the Security
page covers the same ground, with every option preserved:

- Scanner install / update / uninstall / auto-update live on the Scanner setup
  tab (TrivyManager).
- Scan policies, the honor-suppressions toggle, and the replica
  managed-by-control / demote controls move into a new ScanPolicyManager on the
  Policies tab (paid; Community sees only the policy-pack catalog).
- CVE suppressions and acknowledgements remain on the Suppressions tab.

Wiring removed: the registry section and the now-empty Security settings group,
the SectionId, the SettingsSectionContent case and the isPaid prop it was the
sole consumer of, and SecuritySection itself. The dashboard configuration-status
"Vulnerability scanning" row now navigates to the Security page Policies tab.

Docs that pointed at "Settings -> Security -> Vulnerability Scanning" are swept
to the relevant Security page tabs.

* fix: harden Security page scanner refresh, policy-load errors, and secret-only badges

Address independent-review findings on the Security page:

- Scanner setup now refreshes Trivy state when the active node changes, so the
  displayed scanner status matches the node TrivyManager's actions target (both
  follow x-node-id). Previously, switching nodes on the tab left stale state.
- ScanPolicyManager surfaces an explicit error state on a failed policy fetch
  instead of falling through to a false "No scan policies configured".
- The shared SeverityBadge and the Images findings column no longer label a scan
  "clean" when it has secrets or misconfigurations but no CVE severity
  (highest_severity is derived from vulnerabilities only); they show a "Findings"
  state and the secret/misconfig counts instead.
- The Overview enforcement note points to the Policies tab, not the removed
  Settings section.
- The History tab auto-opens the scan-history sheet only on a deep-link (mount
  with the History tab active), not on every manual tab selection.

Adds tests for the badge secret/misconfig state and the policy-load error state.

backend/src/services/DatabaseService.ts

@@ -703,6 +703,8 @@ export interface ScanSummary {
     low: number;
     unknown: number;
     fixable: number;
+    secret_count: number;
+    misconfig_count: number;
     scanned_at: number;
     scan_id: number;
 }
@@ -4451,7 +4453,7 @@ export class DatabaseService {
             .prepare(
                 `SELECT vs.image_ref, vs.id as scan_id, vs.highest_severity, vs.total_vulnerabilities,
                     vs.critical_count, vs.high_count, vs.medium_count, vs.low_count,
-                    vs.unknown_count, vs.fixable_count, vs.scanned_at
+                    vs.unknown_count, vs.fixable_count, vs.secret_count, vs.misconfig_count, vs.scanned_at
                  FROM vulnerability_scans vs
                  INNER JOIN (
                    SELECT image_ref, MAX(scanned_at) AS max_scanned
@@ -4472,6 +4474,8 @@ export class DatabaseService {
                 low_count: number;
                 unknown_count: number;
                 fixable_count: number;
+                secret_count: number;
+                misconfig_count: number;
                 scanned_at: number;
             }>;
         const out: Record<string, ScanSummary> = {};
@@ -4486,6 +4490,8 @@ export class DatabaseService {
                 low: r.low_count,
                 unknown: r.unknown_count,
                 fixable: r.fixable_count,
+                secret_count: r.secret_count,
+                misconfig_count: r.misconfig_count,
                 scanned_at: r.scanned_at,
                 scan_id: r.scan_id,
             };
@@ -4493,6 +4499,43 @@ export class DatabaseService {
         return out;
     }
 
+    /**
+     * Uncapped count of scans in a given status for a node. Unlike
+     * `getVulnerabilityScans`, this never applies the per-image history cap, so
+     * the Security overview reports the true number of (for example) failed
+     * scans rather than a capped grouped total.
+     */
+    public countScansByStatus(nodeId: number, status: VulnScanStatus): number {
+        return (
+            this.db
+                .prepare(
+                    'SELECT COUNT(*) AS cnt FROM vulnerability_scans WHERE node_id = ? AND status = ?',
+                )
+                .get(nodeId, status) as { cnt: number }
+        ).cnt;
+    }
+
+    /**
+     * Count of enabled block-on-deploy policies that are eligible to apply to
+     * this node: fleet-wide (node_id IS NULL) or scoped to this node. Built on
+     * `getScanPoliciesForUi` so a replica never counts policies scoped to a
+     * sibling node's identity. Stack-pattern applicability is not evaluated
+     * (there is no concrete stack name at overview scope), so this is an
+     * approximate "is this node enforcing" indicator, not a per-stack guarantee.
+     */
+    public countEligibleBlockPolicies(
+        nodeId: number,
+        role: 'control' | 'replica',
+        selfIdentity: string,
+    ): number {
+        return this.getScanPoliciesForUi(role, selfIdentity).filter(
+            (p) =>
+                p.enabled === 1 &&
+                p.block_on_deploy === 1 &&
+                (p.node_id === null || p.node_id === nodeId),
+        ).length;
+    }
+
     // --- Scan Policies ---
 
     public getScanPolicies(): ScanPolicy[] {