Backup Ops re-entry can target the wrong Backup after create confirmation is lost #10645

Problem

The Backup Ops path creates a namespaced Backup and then records progress on the OpsRequest. If the controller exits after the Backup create succeeds but before the OpsRequest status update is persisted, the next reconcile must resume the same object.

The previous implementation generated a timestamp-based name and later listed Backups by reusable OpsRequest name/type labels. A retry could generate a second name, or a recreated OpsRequest with the same name could observe an older Backup. Cluster names are also reusable, so name-only incremental-parent ownership can cross backup lineage after a Cluster is deleted and recreated.

Expected behavior

• A generated Backup name is stable for the immutable OpsRequest identity.
• Re-entry accepts an existing Backup only when immutable Ops UID and normalized intent/spec identity match.
• Reconcile reads the exact generated Backup, including confirmation of an informer cache miss.
• Incremental parent reuse requires the DataProtection Cluster UID label to match the current Cluster UID.
• DataProtection policy/method/parent status classification remains owned by the Backup controller rather than being duplicated as an Ops fatal/retryable state machine.