fix(system/bucket): credentials Secret never created when COSI secret appears after first reconcile (lookup-timing) #3247

Summary

The human-friendly credentials Secret produced by the system/bucket chart (<bucketName>-<user>-credentials, e.g. bucket-cozy-backups-system-credentials) is gated on a Helm lookup of the COSI-provisioned BucketInfo Secret. Because the COSI Secret is provisioned asynchronously (after the BucketClaim reconciles) and Helm only re-evaluates lookup on a real chart upgrade, the credentials Secret is never created if the COSI Secret appears after the release's last reconcile. It does not self-heal.

For the platform backup flow this is fatal: backupstrategy-controller projects credentials from bucket-cozy-backups-system-credentials, so a Postgres BackupJob stays stuck forever with CredentialsProjectionPending: source credentials Secret tenant-root/bucket-cozy-backups-system-credentials not found.

Evidence

• packages/system/bucket/templates/user-credentials.yaml renders the -credentials Secret only inside a lookup gate:

  {{- $existingSecret := lookup "v1" "Secret" $.Release.Namespace $secretName }}
  {{- if $existingSecret }}
  ...  name: {{ $secretName }}-credentials
  {{- end }}
  

  $secretName is the COSI BucketInfo Secret (e.g. bucket-cozy-backups-system), which is created asynchronously by the COSI driver after the BucketClaim is provisioned.
• Helm evaluates lookup only during an actual install/upgrade. If the release last reconciled before the COSI Secret existed, lookup returns empty, the -credentials Secret is skipped, and no subsequent reconcile re-renders it (the release is otherwise unchanged). This is the same lookup-timing class as test(e2e): re-enable and modernize the VM backup e2e (backup path is uncovered) #3236.

Observed impact (live v1.5.x, SeaweedFS-backed)

• On a freshly provisioned platform backup bucket, bucket-cozy-backups-system (COSI BucketInfo) existed, but bucket-cozy-backups-system-credentials was absent hours later; the helm release manifest did not contain it.
• Every Postgres BackupJob against cozy-default stayed in CredentialsProjectionPending until the credentials Secret was created manually. It never appeared on its own.

Proposed fix

Remove the dependency on a one-shot lookup, e.g.:

• Have the bucket application controller/driver create the -credentials Secret when the COSI BucketInfo Secret is created (event-driven), instead of relying on a Helm render-time lookup; or
• Add a periodic/bounded requeue so the chart re-renders once the COSI Secret appears (analogous to the fix discussed in test(e2e): re-enable and modernize the VM backup e2e (backup path is uncovered) #3236); or
• Derive the -credentials Secret directly from the COSI provisioning result rather than a template-time lookup.