test(operator): add reconciler tests for FerrVaultSecret and FerrVaultConnection

[BryanFRD]

Problem

The new ferrvault.com/v1alpha1 controllers shipped without any tests:

• internal/controller/ferrvaultsecret_controller.go — no ferrvaultsecret_controller_test.go
• internal/controller/ferrvaultconnection_controller.go — no ferrvaultconnection_controller_test.go

Every prior reconciler got dedicated coverage (see closed #23 for FerrFlowSecret, plus ferrflowconnection_controller_test.go, token_broker_test.go, transforms_test.go, client_test.go). The FerrVault controllers are not thin wrappers — they have their own finalizer (ferrvault.com/secret-cleanup), their own annotations (ferrvault.com/content-hash, ferrvault.com/managed-by), and a loadToken adapter that copies conn.ObjectMeta + conn.Spec into a synthetic FerrFlowConnection to reuse the broker (ferrvaultsecret_controller.go:198-208, ferrvaultconnection_controller.go:142-146). That adapter and the delete-blocking dependant check (handleDelete) are exactly the kind of glue that breaks silently.

Why it matters

The FerrVault CRDs are the forward path for the whole product (the FerrFlow CRDs are slated for removal under #82). Shipping the successor reconcilers untested means the rename migration rides on unverified code in a secrets-handling operator.

Proposed approach

Mirror the existing FerrFlow controller tests:

• FerrVaultSecret: happy-path sync, MissingKeys → Ready=False, transform error, finalizer add/remove, target-Secret create + drift correction, rollout-restart on content change.
• FerrVaultConnection: probe success/failure, DeletionBlocked while dependants exist, finalizer removal once dependants are gone.
• One test asserting the loadToken adapter forwards both tokenSecretRef and oidc modes correctly.

Acceptance criteria

• ferrvaultsecret_controller_test.go and ferrvaultconnection_controller_test.go exist and cover the cases above.
• Coverage for internal/controller does not regress versus the FerrFlow equivalents.