wrong SCOPE by cloning database

Please, answer some short questions which should help us to understand your problem / question better?

• Which image of the operator are you using? registry.opensource.zalan.do/acid/postgres-operator:v1.8.2
• Where do you run it - cloud or metal? Kubernetes or OpenShift? vSphere/Rancher/K8s
• Are you running Postgres Operator in production? yes
• Type of issue? Bug report

I want to upgrade and clone a database with WALG/S3(minio). Old Database is: patroni-12/patroni-12 (namespace/name) and new should be patroni-13/patroni-13.
After startup from the first pod I see in the log:
2022-11-03 13:30:19,738 INFO: trying to bootstrap a new cluster
2022-11-03 13:30:19,740 INFO: Running custom bootstrap script: envdir "/run/etc/wal-e.d/env-clone-patroni-12" python3 /scripts/clone_with_wale.py --recovery-target-time="2022-11-03T08:06:25.351+00:00"
2022-11-03 13:30:20,024 INFO: Trying s3://postgres-backup/spilo/patroni-12/7a5e040d-3821-435b-9c8e-a88b77fda613/wal/13/ for clone
2022-11-03 13:30:30,048 INFO: Lock owner: None; I am patroni-13-0
2022-11-03 13:30:30,048 INFO: not healthy enough for leader race
2022-11-03 13:30:30,112 INFO: bootstrap in progress
...

The restore hangs. In the pod I see that the scope ist patroni-13, but it should be patroni-12:
python3 /scripts/clone_with_wale.py --recovery-target-time=2022-11-03T08:06:25.351+00:00 --scope=patroni-13 --datadir=/home/postgres/pgdata/pgroot/data
For this reason restore cant find a backup

Start with scripts/clone_with_wale.py and inspect how the clone command receives its scope during a database clone. Reproduce the WALG/S3 restore using the issue's old and new cluster names, then verify that the restore searches the old cluster's backup path and completes instead of hanging.