feat: implement TTL secret controller for orphaned secrets cleanup

[piyxsh31]

CHANGE DESCRIPTION

Problem:

When a BackupStorage Custom Resource fails to be created (e.g., due to an API error), the Secret containing the storage credentials that was just created gets left orphaned. Because there's no parent CR, it lacks an OwnerReference and Kubernetes native garbage collection ignores it.

Related pull requests

• fix: implement TTL annotation for backup storage secrets cleanup openeverest#2333

closes: openeverest/openeverest#2332

Cause:
We modified the API handler to apply a TTL annotation instead of doing fragile synchronous deletion on failure. However, the operator needed a mechanism to recognize this annotation and actually perform the asynchronous cleanup of these orphaned Secrets.

Solution:
Introduced a new SecretReconciler (secret_controller.go) to watch and actively delete orphaned Secrets that still carry the expired everest.percona.com/cleanup-after annotation. Updated BackupStorageReconciler to adopt Secrets by stripping this annotation upon successful CR creation.

CHECKLIST

Helm chart

• Is the helm chart updated with the new changes? (if applicable)

Jira

• Is the Jira ticket created and referenced properly?

Tests

• Is an Integration test/test case added for the new feature/change?
• Are unit tests added where appropriate?