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.

frontend/src/components/VulnerabilityScanSheet.tsx

@@ -52,6 +52,7 @@ import type {
   VulnSeverity,
   SecretFinding,
   MisconfigFinding,
+  ScanDetailTab,
 } from '@/types/security';
 
 interface VulnerabilityScanSheetProps {
@@ -62,6 +63,13 @@ interface VulnerabilityScanSheetProps {
   canExportSarif?: boolean;
   canCompare?: boolean;
   canManageSuppressions?: boolean;
+  /**
+   * Tab to open on first load. Defaults to 'vulns' (with the existing
+   * auto-switch to a populated tab when the scan has no vulnerabilities).
+   * Callers that open the sheet from a secret/misconfig context pass the
+   * matching tab so it lands there even when the scan also has CVEs.
+   */
+  initialTab?: FindingTab;
 }
 
 interface SuppressDialogState {
@@ -80,7 +88,9 @@ interface AckDialogState {
 }
 
 type SeverityFilter = 'ALL' | VulnSeverity;
-type FindingTab = 'vulns' | 'secrets' | 'misconfigs';
+// Single source of truth lives in types/security as ScanDetailTab; alias here so
+// the initialTab prop is provably the same type its callers (SecurityView) hold.
+type FindingTab = ScanDetailTab;
 
 const PAGE_SIZE = 25;
 
@@ -113,6 +123,7 @@ export function VulnerabilityScanSheet({
   canExportSarif = false,
   canCompare = false,
   canManageSuppressions: canManageSuppressionsProp = false,
+  initialTab,
 }: VulnerabilityScanSheetProps) {
   const [isReplica, setIsReplica] = useState(false);
   useEffect(() => {
@@ -183,7 +194,11 @@ export function VulnerabilityScanSheet({
       setPage(0);
       setSecretsPage(0);
       setMisconfigsPage(0);
-      if ((scanData.total_vulnerabilities ?? 0) === 0) {
+      if (initialTab) {
+        // Caller asked to land on a specific tab (e.g. opened from the
+        // Secrets or Compose-risks list), which wins over the default.
+        setTab(initialTab);
+      } else if ((scanData.total_vulnerabilities ?? 0) === 0) {
         if ((scanData.misconfig_count ?? 0) > 0) setTab('misconfigs');
         else if ((scanData.secret_count ?? 0) > 0) setTab('secrets');
         else setTab('vulns');
@@ -195,7 +210,7 @@ export function VulnerabilityScanSheet({
     } finally {
       setLoading(false);
     }
-  }, [scanId]);
+  }, [scanId, initialTab]);
 
   useEffect(() => {
     setCompareOpen(false);