fix(operator): keep an existing target and the connection token intact when keys are missing

[BryanFRD]

Makes it safe for a FerrVaultSecret to sync a connection's own token Secret, so operator tokens can be rotated from FerrVault (create the new token into the vault, the operator writes it into the token Secret, then revoke the old one).

What changed:

• When the reveal reports missing keys and the target Secret already exists, the target is left untouched (Ready=False MissingKeys). Before, the target was rewritten with only the keys found (Data=nil, StringData=found), so a missing key deleted the value from a working Secret.
• No empty target is created when nothing was found (the ferrlens-headless-token case: an empty Secret appeared and consumers restarted on it).
• Missing keys are retried within a minute instead of waiting a full refresh interval, so a value added after the FerrVaultSecret is picked up quickly (part of FerrLabs/Infra#793).
• When the target is the Secret named by the connection's tokenSecretRef, the FerrVaultSecret no longer sets itself as controller owner (and drops an existing reference). Deleting the FerrVaultSecret, or a Flux prune, would otherwise garbage-collect the token and lock the connection out.
• In that case, if the synced data has no key matching tokenSecretRef.key, the target is left alone with Ready=False TokenKeyMissing.

New targets with a partial reveal are still created with the keys found, as before.

Tests in ferrvaultsecret_guard_test.go cover each case; breaking the missing-key guard or the ownership skip makes them fail. go test -race ./... passes locally. golangci-lint was not available locally, CI runs it.

[ferrfleet]

The guards look correct. A partial reveal no longer rewrites an existing target. An empty reveal doesn't create an empty Secret. A target that holds the connection token is only written when the token key is present, and it no longer carries an owner reference, so deleting the CR won't garbage-collect it. Missing keys now requeue within a minute. The tests cover each of these paths.

Nit: targetContentHash in ferrvaultsecret_sync.go (around line 198) still works out the target name by hand. Replace those four lines with name := targetName(cr) so every caller uses the same lookup. That code isn't in the diff, so I couldn't attach a suggestion to it.

[BryanFRD]

Applied the targetName nit in targetContentHash, and renamed the owner UID test constant that gitleaks read as a key (it is a fixed fake UID). Kept the small owner-ref helper: RemoveOwnerReference errors when the reference is absent, so the helper stays simpler than a HasOwnerReference guard plus RemoveOwnerReference.

[ferrfleet]

48811cd fixes the targetContentHash nit: it now uses targetName(cr). The fixture rename doesn't change behaviour. No new findings.