OneToOne scale-out restore maps source Pods by list position

[leon-ape]

Problem

Horizontal scale-out creates one Restore per new Pod. The Restore must keep the actual target Pod ordinal when constructing the target PVC and Pod identity.

For OneToOne restore, BackupStatusTarget.SelectedTargetPods is an unordered list and has no contract that array position equals Pod ordinal. The list may be filtered by instance template, contain ordinal holes, or contain multiple templates that reuse the same numeric ordinal.

For example:

SelectedTargetPods = ["redis-az-a-3", "redis-az-a-4"]

Restoring target Pod redis-az-a-3 must select source Pod redis-az-a-3. Looking up SelectedTargetPods[3] is out of range.

The snapshot path may consequently create a PVC without a snapshot dataSource, while the prepare-data path may skip its restore Job. Claim-template metadata is also shallow-copied in the snapshot loop, allowing one replica Pod identity label to leak into the next replica.

Expected behavior

• Preserve the actual scale-out target Pod ordinal in the generated per-Pod Restore.
• Treat SelectedTargetPods as an unordered set.
• For OneToOne prepareData, match the source by stable target identity: exact Pod name when possible, otherwise instance-template plus ordinal, or a unique flat ordinal.
• Reject missing or ambiguous mappings instead of silently producing an empty restore.
• Keep replica-specific claim metadata independent.

Affected releases

The positional source-selection behavior exists in main, release-1.1, and release-1.0. The main patch does not apply cleanly to either release branch, so both releases need independently adapted fixes.