Add table-driven tests for operation-specific controller wiring

[JaydipGabani]

Parent issue: #3964
Behavior gaps: #4770, #4771
Dependency cleanup: #4772, #4773, #4774, #4775

Describe the solution you'd like

Add a focused, table-driven test suite that verifies Gatekeeper's controller and dependency plan for every independently selectable --operation value.

pkg/operations/operations_test.go currently verifies only flag parsing. There is no test that exercises setupControllers or an equivalent wiring plan for isolated operations. As a result, these contradictory paths were not detected:

• status causes constraint-client initialization but supplies no enforcement point.
• generate owns CRD/VAP/VAPB behavior but does not start the ConstraintTemplate/Constraint reconcilers.
• Non-mutation and feature-disabled processes still receive several unused systems and runnables.

Suggested scope:

• Extract the smallest pure/testable operation-to-capability plan needed by setupControllers, or add injectable dependency factories that let tests observe actual construction and registration.
• Ensure production wiring consumes the exact plan under test; avoid a parallel test-only mapping.
• Cover every isolated operation: audit, webhook, mutation-webhook, mutation-controller, mutation-status, status, and generate.
• Cover representative combinations used by shipped manifests, including audit+status+mutation-status+generate, webhook+mutation-webhook, and the default all-operations case.
• Include relevant feature toggles for expansion, external data, violation export, and VAP scope synchronization.

Acceptance criteria:

• Each table row asserts which clients/systems/runnables/controllers are constructed and which are intentionally absent.
• Tests assert that every registered consumer receives its required non-nil dependencies and that no review client is created without a valid enforcement point.
• Status-only and generate-only expectations match their documented behavior.
• Feature-disabled rows prove their optional dependencies are not constructed.
• At least one focused test exercises real setup/registration behavior rather than only testing predicate helpers.
• The PR demonstrates that the relevant regression assertions fail when the corresponding production guards are reverted.

Environment:

• Gatekeeper version: current master
• Kubernetes version: use the repository's supported envtest version for API-backed cases

[shashankvarma499]

Hi @JaydipGabani — I opened #4813 for this (operation-to-capability Plan + table-driven tests covering all isolated operations, shipped combinations, and feature toggles).

One coordination note before review: the sibling dependency-cleanup PR #4784 (for #4775, cc @anneheartrecord) introduces pkg/operations/capabilities.go and also rewires setupControllers in main.go. My #4813 introduces a pkg/operations/plan.go Plan abstraction in the same files, so the two are likely to collide in main.go/pkg/operations.

I'd like to align on the shared abstraction (plan vs. capabilities) so we don't produce two conflicting rewires of the same wiring. Happy to rebase #4813 on top of #4784, or split out just the table-driven test suite, whichever the maintainers prefer.