feat(patrol): allow reopening dismissed findings

docs/release-control/v6/internal/subsystems/agent-lifecycle.md

@@ -48,6 +48,10 @@ initial notification target into the notification manager. This adjacent
 alerts/notifications wiring grants no agent enrollment, reporting, removal,
 profile, update, probe-assignment, or command authority and must not mutate
 host-agent state.
+The shared `internal/api/ai_handlers.go` route may also reopen a dismissed
+Patrol finding and mirror that state into the unified findings store. This is
+AI finding-state management only; it grants no agent enrollment, report,
+profile, update, removal, command, or fleet-control authority.
 The JSON-excluded Proxmox VM/LXC I/O-rate validity fields carried by
 `internal/models/models.go` are likewise monitoring-owned sidecar evidence.
 They distinguish a valid idle interval from an unknown rate for history,

docs/release-control/v6/internal/subsystems/ai-runtime.md

@@ -35,6 +35,11 @@ read-state is available and the shared Proxmox guest CPU-percent normalizer for
 legacy snapshot fallback. It must not independently rescale by configured cores
 or substitute a linked in-guest host-agent CPU value, so Patrol evaluates the
 same guest observation as dashboard, alerts, and history.
+Dismissed Patrol findings remain durable operator history. Reopening a
+finding-backed suppression row must use the canonical undismiss transition:
+clear dismissal, suppression, acknowledgement, and reminder state; preserve the
+operator note; append an `undismissed` lifecycle event; and immediately mirror
+the reopened state into the unified findings projection.
 
 Interactive Assistant invocation authority is fail-closed and request-local.
 The `read_only` presentation means no model-invokable durable Pulse-state or

docs/release-control/v6/internal/subsystems/api-contracts.md

@@ -29,6 +29,11 @@ The accepted values are `all`, `email`, `webhook`, and `apprise`; the backend
 normalizes aliases and invalid values before responding, persisting, and
 updating the live notification runtime. Escalation levels use the same value
 vocabulary but remain independent of the initial target.
+`DELETE /api/ai/patrol/suppressions/finding_{findingID}` is the canonical
+reopen path for a dismissed Patrol finding. It removes the finding-backed
+suppression row, preserves the operator note, clears dismissal state in both
+the Patrol and unified stores, and returns not-found when the row is not
+currently dismissed or suppressed.
 Physical-disk payloads preserve optional SMART counter presence, including
 explicit zero values, and expose provider vendor metadata without converting
 missing data into health. Unified-resource clients may request bounded server

docs/release-control/v6/internal/subsystems/frontend-primitives.md

@@ -27,6 +27,11 @@ The alert schedule's initial-delivery selector composes `SettingsPanel` and
 exposes the same email, webhook, Apprise, and all-destination labels used by
 escalation. It must not introduce a page-local select shell or a second
 destination-label map.
+The centralized Findings surface loads active and historical Patrol findings,
+keeps operator notes editable (including clearing a note with an empty value),
+and exposes `Reopen finding` only for dismissed rows. Reopening uses the
+finding-backed suppression removal API, refreshes both unified and Patrol
+history, and must not discard the saved note.
 
 Platform-owned workload controls extend the shared `WorkloadsFilter` view
 options rather than creating page-local toolbar shells. The Proxmox overview

docs/release-control/v6/internal/subsystems/patrol-intelligence.md

@@ -18,6 +18,11 @@
 Own the Patrol intelligence route shell, feature surface, local state
 orchestration, findings and approval presentation, run-history rendering, and
 Patrol-specific presentation helpers.
+The centralized Findings surface loads full history for its All and Resolved
+filters, keeps saved operator notes editable and clearable, and offers
+`Reopen finding` only on dismissed findings. Reopening removes the
+finding-backed suppression row, refreshes both Patrol and unified finding
+sources, and retains the note as operator context.
 
 ## Canonical Files
 

docs/release-control/v6/internal/subsystems/storage-recovery.md

@@ -39,6 +39,10 @@ The shared alerts API may persist and apply `schedule.initialNotify` for email,
 webhook, or Apprise delivery. That notification routing is not storage-health,
 backup, recovery-point, restore, or protection evidence; storage/recovery
 surfaces must not infer product state from the selected destination.
+The shared AI handlers may reopen dismissed Patrol findings and synchronize
+the unified finding projection. That finding-state transition does not create,
+delete, validate, or restore recovery points and must not be treated as
+storage-health, backup, restore, or protection evidence.
 The shared Proxmox config discovery path likewise persists powered-off cluster
 members and separates membership from member API reachability. Storage and
 recovery consumers may use the resulting provider-scoped node/instance