Fix VDS bug where 2 leases are being generated on initial deployment

[Zlaticanin]

This PR fixes a race condition that could cause two Vault leases to be created during the initial reconcile of VDS. This happened because the finalizer was added after the status update (LastGeneration = generation), which caused the generation to be bumped again, triggering another reconcile that passed the predicate filters and re-ran sync logic.

I moved the maybeAddFinalizer logic to run before setting status or performing sync logic. If a finalizer is added, we requeue and exit early. By doing this the generation bump caused by adding the finalizer is processed cleanly, and the reconcile won't proceed to status updates or sync logic prematurely.

[benashz]

Could we add tests for this case.

[tvoran]

There's a comment in maybeAddFinalizer():

vault-secrets-operator/controllers/common.go

Lines 248 to 249 in e024c75

	// always call maybeAddFinalizer() after client.Client.Status.Update() to avoid
	// API validation errors due to changes to the status schema.

Any concern with API validation errors now that maybeAddFinalizer() is being called before updateStatus()?

[Zlaticanin]

Thank you for reviewing! My understanding for the comment is that an API validation error would happen if both metadata (finalizers) and status of a resource are updated in the same reconcile pass. But in our case, we are calling maybeAddFinalizer() first, and if a finalizer is added, we exit early and requeue. So we shouldn't be touching the status in the same loop, which would avoid the validation issue because the next reconcile handles the status update separately. Please let me know if I am misunderstanding!