What would you like to be added:

Add admission control for the Karmada Operator :

• Mutating webhook to apply sensible defaults.
• Validating webhook to reject invalid specs.

To maintain backwards compatibility, registration and wiring of admission webhooks will be controlled via a flag that is off by default. As such, unless explicitly enabled when deploying the operator, the current behavior with both defaulting and validations running during reconciliation in the operator will be maintained.

Why is this needed:

• Best practice: Admission webhooks are the Kubernetes-native way to enforce policy and defaults at the API boundary; they provide consistent behavior across all clients and earlier, clearer feedback.
• Problems with in-controller defaulting/validation:
  • Unnecessary reconciles & retries: Invalid specs pass admission, then fail in reconcile, causing requeues, wasted compute, and noisy logs.
  • Slower feedback loops: Errors surface only after controller processing, increasing feedback latency for users and automation.
  • Race/ordering issues: Defaulting/validation inside the controller happens after the object is stored. If a user (or GitOps) sends rapid, conflicting updates, the controller can see transient, invalid specs and thrash before it settles. Admission stops bad states before they hit storage.