Vendor refresh still expects the previous cert-approver resource #5188

🤖 Generated by the Agentic Engineer

Description

The maintained vendor refresh rejects the already-adopted cert-approver 0.12.1 resource, so an unrelated origin-ca-issuer source update cannot be completed. PR #4114 updated the source, image and startup probe but retained the finding fingerprint for the preceding 0.12.0 Deployment.

Steps to Reproduce

1. Use the reviewed vendor updater with pinned Checkov 3.3.9.
2. Run its remote refresh at fix(deps): complete origin-ca vendor refresh #5185's source-commit update.
3. Both origin-ca-issuer CRDs pass their unchanged SHA-256 checks, then the cert-approver finding validator rejects the existing Deployment before any generated file is replaced.

Expected Behavior

The audited current upstream resource passes its configured finding binding, and modified resources or evaluated keys still fail. Vendor refresh completes through the maintained generator.

Actual Behavior

The downloaded cert-approver source matches the pinned 0.12.1 digest, but its deployment fingerprint is rejected. Independently reversing only #4114's image change and startup-probe addition reproduces the stored 0.12.0 fingerprint exactly. Existing unit fixtures recompute their own target fingerprints and miss this real-resource mismatch.

Acceptance Criteria

• A real Checkov finding fixture is bound to the committed current Deployment, fails before the repair and passes afterward.
• Re-review the complete chore(deps): update dependency alex1989hu/kubelet-serving-cert-approver to v0.12.1 #4114 Deployment diff before updating its finding fingerprint; retain all check identities, evaluated-key checks, source digests and existing negative controls.
• The actual maintained remote refresh completes with Checkov 3.3.9, including its secret canaries and approved-disposition checks.
• Existing annotator and source-pin regression suites pass, followed by exact-head hosted validation and review.

Part of #4979. Required to complete #5185; the repair belongs with that existing update rather than a replacement dependency PR.