Add event-driven drift detection for VSS/VDS destination Secrets

[pavankatukuri6456]

Watch destination Secrets owned by VaultStaticSecret (hmacSecretData=true) and VaultDynamicSecret (allowStaticCreds=true) for out-of-band .Data changes, and enqueue the owning CR for reconciliation immediately instead of waiting on the next poll/requeue. Repair logic is unchanged: the existing secretMAC/HMAC comparison already re-validates the live destination Secret on every Reconcile, so this only changes when that check runs, not how drift is detected or repaired.

• enqueueOnDataChangeRequestHandler (controllers/eventhandlers.go) maps a Secret Update event to its owning CR via OwnerReferences, fetches that CR, and only enqueues it if the CR has opted in (HMACSecretData for VSS, AllowStaticCreds for VDS). CRs that haven't opted in see no behavior change.
• secretDataChangedPredicate (controllers/predicates.go) filters Update events to only those where .Data actually changed, so metadata-only Secret writes (labels/annotations/resourceVersion bumps) never reach the handler.
• Both controllers register an additional Watches(&corev1.Secret{}, ...) alongside the existing metadata-only deletion watch.
• main.go scopes the manager's default cache for Secrets to VSO-owned Secrets only (via the same owner-label selector already applied to every destination Secret), so the new full-object watch does not reintroduce cluster-wide Secret caching.

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.

• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.

• If applicable, I've documented the impact of any changes to security controls.

  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}