feat(recovery): make rollback-recovery image lifecycle visible and controllable (#1753)

* feat(recovery): make rollback-recovery image lifecycle visible and controllable

GitHub discussion #1751 asked why Sencho creates sencho-rb/<id>/<service>:hold
images during automatic updates and how to clean them up. That surfaced a real
safety bug alongside the missing visibility: the manual single-image delete
route did not consult the held-image predicate every other deletion path
already honors, so a user could delete a rollback-protected image straight
through the Images tab and silently break automatic recovery for that update.
A short/truncated id also bypassed the predicate's full-id lookup.

Fixes:
- POST /images/delete now resolves the submitted id to its canonical form and
  checks the unified held-image predicate before deleting, returning 409
  IMAGE_HELD_FOR_ROLLBACK for a protected image.
- The Images tab no longer mislabels a protected image as plain "Unused"; a
  fully-synthetic hold image is kept out of the generic inventory entirely and
  surfaced instead in a new Resources -> Rollback tab, with an additive
  "Rollback protected" badge for images that still carry a normal tag too.

New capability:
- Two settings (Deploy Guardrails): superseded-generation retention (days,
  replaces a hardcoded 7) and a cap on retained generations per stack.
- A new Resources -> Rollback tab lists every generation (stack, short id,
  state, retention) with an admin-gated manual release action, including
  releasing the current generation with an explicit warning that automatic
  rollback becomes unavailable until the next successful update. Release is
  a single atomic, server-revalidated transition so a stale UI read can never
  release a row that has since become ineligible.

Also consolidated three near-duplicate implementations of the held-image
predicate (two of which relied on a require() of a sibling .ts file that
silently failed to resolve under the test runner and was never actually
exercised by a real test before this change) into one shared module.

Known follow-up, not fixed here: an orphaned sencho-rb tag whose recovery row
no longer exists (DB restore, node re-add) is invisible in both the Images
and Rollback tabs with no UI path to reclaim it.

* fix(audit): add summary mapping for rollback generation release

* fix(security): sanitize prune target in log sinks and cover release RBAC

Closes two open js/log-injection findings on the system prune route by
applying the same inline sanitizeForLog barrier the rest of the file
already uses. The prune target is validated against an enum by
parsePruneTargets before reaching these sinks, so the findings were false
positives, but the barrier is cheap and removes the standing alerts on a
file this change already touches. Also wraps the generation id in the
release log line for consistency with the stack name beside it.

Adds coverage for gaps a QA pass identified:
- Release endpoint refuses a viewer and a deployer (Admin-only), leaving
  the generation and its artifacts untouched.
- Viewer can still read the generations list, matching the sibling
  Resources routes.
- The predicate the prune routes build reports full-stack rollback holds,
  not just service-scoped ones, and re-reads per call so a hold taken
  between plan and delete still gates the delete.
- After releasing the current generation, no rollback point is claimed
  for the stack through any consumer of the current-generation lookup.

backend/src/services/DockerController.ts

@@ -143,6 +143,9 @@ export interface ClassifiedImage {
   managedBy: string | null;
   managedStatus: 'managed' | 'unmanaged' | 'unused';
   isSencho: boolean;
+  /** True when a StackUpdateRecoveryService/ServiceUpdateRecoveryService hold protects this image from pruning. Additive: does not change managedStatus semantics. */
+  rollbackProtected: boolean;
+  rollbackProtectionKind?: 'stack' | 'service';
 }
 
 export interface PortInUseInfo {
@@ -561,23 +564,52 @@ class DockerController {
 
     const selfIdentity = SelfIdentityService.getInstance();
 
-    const images: ClassifiedImage[] = this.validateApiData<any[]>(rawImages).map((img: any) => {
-      const usedByStacks = [...(imageToStacks.get(img.Id) ?? [])].sort((a, b) => a.localeCompare(b));
-      const managedBy = usedByStacks[0] ?? null;
-      const managedStatus: ClassifiedImage['managedStatus'] =
-        img.Containers === 0 ? 'unused' :
-        managedBy ? 'managed' : 'unmanaged';
-      return {
-        Id: img.Id,
-        RepoTags: img.RepoTags ?? [],
-        Size: img.Size ?? 0,
-        Containers: img.Containers ?? 0,
-        usedByStacks,
-        managedBy,
-        managedStatus,
-        isSencho: selfIdentity.isOwnImage(img.Id),
-      };
-    });
+    // Dynamic (async) imports avoid a static cycle: StackUpdateRecoveryService
+    // imports DockerController directly, and ServiceUpdateRecoveryService
+    // reaches it transitively through ComposeService. It must be `await import`
+    // rather than require(), which does not resolve under Vitest's loader.
+    const { StackUpdateRecoveryService } = await import('./StackUpdateRecoveryService');
+    const { ServiceUpdateRecoveryService } = await import('./ServiceUpdateRecoveryService');
+    const stackHeld = StackUpdateRecoveryService.getInstance().getHeldImageIds(this.nodeId);
+    const serviceHeld = ServiceUpdateRecoveryService.getInstance().getHeldImageIds(this.nodeId);
+    // A null lookup means "held state unknown" (the DB read failed); treat it
+    // as held so the badge never disagrees with the delete guard, which fails
+    // the same way (recoveryHeldImages.ts's buildUnifiedHeldImagePredicate).
+    const rollbackKind = (imageId: string): ClassifiedImage['rollbackProtectionKind'] => {
+      if (stackHeld === null || stackHeld.has(imageId)) return 'stack';
+      if (serviceHeld === null || serviceHeld.has(imageId)) return 'service';
+      return undefined;
+    };
+
+    // Only hide an image from the generic inventory when every visible tag is
+    // a synthetic sencho-rb hold tag; an image that also carries a normal
+    // registry tag stays visible here (with the badge below) so the generic
+    // inventory stays complete. Its generation still surfaces in the Rollback tab.
+    const isFullySyntheticHoldImage = (repoTags: string[]): boolean =>
+      repoTags.length > 0 && repoTags.every((tag) => tag.startsWith('sencho-rb/'));
+
+    const images: ClassifiedImage[] = this.validateApiData<any[]>(rawImages)
+      .map((img: any) => {
+        const usedByStacks = [...(imageToStacks.get(img.Id) ?? [])].sort((a, b) => a.localeCompare(b));
+        const managedBy = usedByStacks[0] ?? null;
+        const managedStatus: ClassifiedImage['managedStatus'] =
+          img.Containers === 0 ? 'unused' :
+          managedBy ? 'managed' : 'unmanaged';
+        const rollbackProtectionKind = rollbackKind(img.Id);
+        return {
+          Id: img.Id,
+          RepoTags: img.RepoTags ?? [],
+          Size: img.Size ?? 0,
+          Containers: img.Containers ?? 0,
+          usedByStacks,
+          managedBy,
+          managedStatus,
+          isSencho: selfIdentity.isOwnImage(img.Id),
+          rollbackProtected: rollbackProtectionKind !== undefined,
+          rollbackProtectionKind,
+        };
+      })
+      .filter((img) => !isFullySyntheticHoldImage(img.RepoTags));
 
     const volumes: ClassifiedVolume[] = rawVolumes.map((vol: any) => {
       const stack = DockerController.resolveProjectLabel(vol.Labels?.['com.docker.compose.project'], knownSet, projectToStack);
@@ -1504,6 +1536,23 @@ class DockerController {
     return { inspect, history };
   }
 
+  /**
+   * Resolve any valid Docker image reference (full ID, short ID, digest, or
+   * tag) to its canonical full sha256 ID. isValidDockerResourceId accepts
+   * short IDs down to 12 hex chars, which a held-image-id set lookup (always
+   * keyed on the full 64-char form) would miss without this resolve step.
+   * Returns null when the image does not exist.
+   */
+  public async resolveImageId(id: string): Promise<string | null> {
+    try {
+      const info = await this.docker.getImage(id).inspect();
+      return info.Id;
+    } catch (error) {
+      if ((error as { statusCode?: number })?.statusCode === 404) return null;
+      throw error;
+    }
+  }
+
   public async removeVolume(name: string) {
     const volume = this.docker.getVolume(name);
     await volume.remove({ force: true });