fix(scheduledbackup): adopt existing Backup instead of looping on AlreadyExists (#10612)

If a previous reconcile created a Backup but the status patch never
landed (lost response from the apiserver, transient error), the controller got
stuck. The next Backup name is deterministic, so every retry recomputed
the same name, the apiserver replied AlreadyExists, and the controller
looped forever - emitting a warning event each time. The only way out
was deleting the orphan Backup by hand.

The reconcile now reads the apiserver state before acting: if a Backup
for the next scheduled iteration is already there, it's adopted and the
schedule moves forward. Creating a new Backup happens only when there
isn't one. If a race ever leaves us with an unexpected duplicate, the
controller requeues briefly and the next pass picks it up.

Existing ScheduledBackup resources unblock themselves once the orphan
Backup reaches a terminal phase (Completed or Failed). If the orphan
is stuck in an earlier phase, the SB still waits on it; that case is
unchanged by this PR.

Closes #10562

Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>