Fix backup orphan inventory readiness

Refs #1352

docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-backup-orphan-readiness-2026-05-01.md

@@ -0,0 +1,49 @@
+# Known RC Issue Closure For GA Backup Orphan Readiness Record
+
+- Date: `2026-05-01`
+- Gate: `known-rc-issue-closure-for-ga`
+- Result: `passed`
+
+## Context
+
+The v5 maintenance delta audit found that `#1352` had not been carried into the
+v6 backup-alert path. Pulse v5 learned not to run backup orphan detection before
+Proxmox template inventory was ready, because backup polling can race ahead of
+guest and template discovery during startup.
+
+The v6 runtime no longer evaluates raw storage backup arrays directly; it
+evaluates recovery rollups. That made the v5 patch non-cherry-pickable, but the
+same failure mode still applied: an old PVE backup whose VMID was not yet in
+the current guest/template inventory could be marked as an orphaned backup-age
+alert.
+
+## Disposition
+
+The v6 candidate now carries an inventory-aware backup alert boundary:
+
+- `internal/alerts/alerts.go` keeps the existing `CheckBackups` API for direct
+  callers and adds `CheckBackupsWithInventory` for monitoring-owned runtime
+  evaluation.
+- PVE orphaned backup alerts now require per-instance, per-guest-type inventory
+  readiness before unresolved PVE backup subjects can alert.
+- Known Proxmox template VM/container subjects are carried as backup-valid
+  subjects and skipped from orphaned backup-age alert creation.
+- Monitoring records Proxmox template subjects from both the efficient
+  `cluster/resources` poll and the traditional VM/container poll fallback, and
+  passes that scoped inventory into backup alert evaluation.
+- PBS/PMG rollup behavior remains unchanged, so external backup-only subjects
+  can still alert when no matching local guest exists.
+
+## Proof
+
+- `go test ./internal/alerts -run 'TestCheckBackups(SkipsPVEOrphanUntilInventoryReady|CreatesPVEOrphanWhenInventoryReady|SkipsKnownPVETemplateBackupSubject|SkipsOrphanedWhenDisabled|HandlesPbsOnlyGuests|VMIDCollision)' -count=1`
+- `go test ./internal/monitoring -run 'TestPVEBackupTemplateInventoryScopeFromClusterResources|TestBuildGuestLookupsFromReadState' -count=1`
+- `go test ./internal/alerts -count=1`
+- `go test ./internal/monitoring -count=1`
+
+## Outcome
+
+The v6 recovery-rollup alert path no longer knowingly regresses v5 `#1352`.
+PVE backup orphan alerts wait for the owning Proxmox inventory signal, and
+template backups do not become false orphaned backup alerts just because
+templates are excluded from normal workload resources.

docs/release-control/v6/internal/status.json

@@ -4403,6 +4403,12 @@
           "kind": "file",
           "evidence_tier": "managed-runtime-exercise"
         },
+        {
+          "repo": "pulse",
+          "path": "docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-backup-orphan-readiness-2026-05-01.md",
+          "kind": "file",
+          "evidence_tier": "managed-runtime-exercise"
+        },
         {
           "repo": "pulse",
           "path": "docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-blocked-2026-05-01.md",

docs/release-control/v6/internal/subsystems/alerts.md

@@ -156,6 +156,13 @@ and identity first-seen tracking. Generic threshold reevaluation must not keep
 or resurrect image-update alerts after their owning Docker alert configuration
 has disabled them.
 
+Backup orphan evaluation is also inventory-scoped. The alerts runtime may
+evaluate recovery rollups for backup age, but unresolved Proxmox PVE backup
+subjects must not be treated as orphaned until monitoring has supplied the
+matching per-instance guest-type inventory readiness signal. Known Proxmox
+template subjects are valid backup subjects, not orphaned workload backups,
+even though templates remain excluded from normal runtime workload resources.
+
 Alert history persistence is also part of that canonical boundary. The history
 manager may choose the owned runtime data directory, but it must normalize that
 directory once and then resolve only the fixed `alert-history.json` and

docs/release-control/v6/internal/subsystems/monitoring.md

@@ -865,6 +865,13 @@ record whose canonical status remains `available` whenever any reporting node
 still has the shared target active; node-local inactive copies may expand node
 affinity, but they must not downgrade the cluster record into an offline
 projection just because that node won the capacity sample.
+That same monitoring-owned Proxmox backup boundary also owns the inventory
+readiness signal used by backup orphan alerts. `internal/monitoring/` must
+record when PVE VM and container inventory has successfully observed a given
+instance and guest type, including template VMIDs that are intentionally
+excluded from normal workload resources. Backup alert evaluation may then
+receive that scoped signal from monitoring, but alert code must not infer PVE
+orphan readiness from recovery rollups alone.
 That same monitoring-owned host-agent ingest boundary now also owns
 vendor-managed NAS RAID normalization. `internal/monitoring/monitor_agents.go`
 must filter vendor-managed system arrays through the shared