Support mergeStrategy: patch on destination to preserve keys not managed by VSO

[Fiv3H3ad]

Is your feature request related to a problem? Please describe.
When using VaultStaticSecret to sync Vault data into a pre-existing Kubernetes Secret, the operator replaces the entire .data map on every sync cycle. This destroys any keys that were written by other controllers or applications at runtime.

Our concrete case: ArgoCD stores its configuration in a single argocd-secret. Some keys are static and should come from Vault (OIDC credentials, admin password, server secret key), while others are generated at runtime by ArgoCD itself (e.g. accounts.<user>.tokens). ArgoCD's ConfigMap uses $key substitution which is hardcoded to read from argocd-secret — there is no way to redirect it to a different secret.

Every VSO refresh cycle wipes the ArgoCD-generated tokens because VSO replaces the full .data map rather than patching only its managed keys.

Describe the solution you'd like

A mergeStrategy field (or similar) on spec.destination:

spec:
  destination:
    name: argocd-secret
    create: false
    mergeStrategy: patch
    transformation:
      templates:
        admin.password:
          text: '{{ .Secrets.adminPassword }}'

Strategy	Sync Behavior
replace (default, current)	Replace entire .data with synced keys
patch / merge	Only add/update the keys VSO manages, leave all other keys untouched

Describe alternatives you've considered

• Separate secret + envFrom: Doesn't work for ArgoCD because $key substitution is hardcoded to argocd-secret.
• Including all keys in Vault templates: Not possible when keys are generated at runtime with dynamic data (UUIDs, timestamps).
• External Secrets Operator: Supports creationPolicy: Merge which solves this. Switching operators is a heavy migration though.
• ricoberger/vault-secrets-operator: Supports reconcileStrategy: Merge. Same migration concern.

Additional context

Related issues that touch on this but don't address preserving pre-existing keys during ongoing sync:

• Merge multiple vault secrets into one K8s secret #118 — Merge multiple vault secrets into one K8s secret
• Populate a single kubernetes secret from multiple Vault secrets #923 — Populate a single kubernetes secret from multiple Vault secrets
• VaultStaticSecret merge secrets from multiple path to one kubernetes secret #954 — VaultStaticSecret merge secrets from multiple paths
• Cannot overwrite existing secrets  #337 — Cannot overwrite existing secrets

This is a blocker for any application that uses a single shared secret for both static config and runtime-generated data with hardcoded secret references (ArgoCD, Grafana, etc.).

[loki344]

We're hitting the exact same problem. In our setup we need to sync credentials from Vault into a secret that's shared with runtime-generated data. Having to choose between "use VSO" and "keep runtime keys" shouldn't be a tradeoff. A mergeStrategy: patch would also naturally solve the multi-path use case since you could point multiple VaultStaticSecret resources at the same destination without them clobbering each other's keys. Worth noting though that the current ownership model would still block that — VSO stamps secrets.hashicorp.com/vso-ownerRefUID on the destination secret, so a second VaultStaticSecret targeting the same secret gets rejected because it's already owned by the first one. A patch strategy would need to support shared ownership or drop the single-owner constraint for merge mode.