GeezerVison

What this PR does

Stacked on #5221; review that one first. Once it merges this PR retargets to main.

A CNPG restore took the destination path and endpoint of the source from the Backup artifact, but the credentials Secret, its key names and the endpoint CA from the CNPG strategy as it reads at restore time. Once the strategy pointed at another bucket or endpoint, the restore combined the recorded location with access settings meant for a different one, and recovery failed after an in-place restore had already purged the target Cluster.

The destination record that #5221 annotates on the cnpg.io/Backup now also carries the key names and the CA, and the artifact copies them into driverMetadata["cnpg.io/archive-access"]. The size probe reads them from there too. The restore picks the access as follows:

1. While the strategy still points at the same endpoint and S3 bucket as the artifact, the strategy's access is used, exactly as before. WAL archiving keeps proving that access against the archive, and it carries any credential rotation since the backup, after which the recorded Secret may already be revoked. The prefix inside the bucket is not compared, since access is taken to be granted per bucket.
2. Once the archive has moved, the recorded access is used if its Secret and CA Secret exist and hold non-empty values under the recorded keys.
3. Otherwise the strategy's access is used, as before, with a RecordedArchiveAccessUnavailable Warning event on the RestoreJob. Credentials wider than one bucket can still read the old archive with it.

An unreadable record fails the RestoreJob, and an error reading a Secret is retried, both before the HelmRelease is suspended and the target is purged. Artifacts written before this change keep working: one that records only the Secret uses it with the strategy's key names and CA once the archive has moved, and one without any record uses the strategy.

This narrows the behaviour the issue asks for ("the recorded Secret, key names and CA, falling back to the strategy only for artifacts that carry no record") in two places, points 1 and 3 above, so that rotating credentials for an archive that has not moved, and deleting the old Secret after a move, keep working as they did. One case remains uncovered: a recorded Secret that still exists but whose keys were revoked, after the archive moved, while the strategy's credentials could still read the old bucket.

Screenshots

Not applicable: no UI change.

Downstream repositories

The diff touches only internal/backupcontroller: no CRD, values, chart or naming change, so nothing in the trigger map applies.

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up:
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:
• cozystack/community - follow-up:

Release note

fix(postgres): restoring a Postgres backup after its CNPG strategy moved to another bucket or endpoint now reaches the archive with the credentials Secret, key names and CA the backup was written with, as long as those Secrets still exist; otherwise, and for an archive that has not moved, the strategy's current access is used as before.