…ent dispatching (#50206)

### What does this PR do?

Introduces a `DatadogInstrumentation` CRD controller in the Cluster Agent that watches `DatadogInstrumentation` custom resources and dispatches section-level events (`EventCreate`, `EventUpdate`, `EventDelete`) to product-specific handlers.

- **Controller** (`pkg/clusteragent/instrumentation/`): Uses a key-only workqueue with a `lastSeen` store to diff current state (from the informer cache) against the last successfully reconciled state. This gives natural deduplication and prevents stale-snapshot bugs on requeue.
- **`Handler` interface**: Product handlers implement `HasSection`, `Handle`, `Validate`, and `SupportsTarget`. Each handler owns a section of the CR spec and only receives events when its section changes.
- **Status conditions**: After handlers run, the leader writes `metav1.Condition` entries back to `.status.conditions` with conflict retry.
- **Autodiscovery handler stub**: Skeleton handler that checks for `spec.config.checks` presence. Returns `ConditionUnknown` until check delivery is implemented in a follow-up.
- **Registration**: Gated behind `datadog_instrumentation.enabled: true` in the Cluster Agent controller catalog.

### Motivation

Part of the [DatadogInstrumentation CRD initiative](https://datadoghq.atlassian.net/wiki/spaces/CONTP/pages/6564659495/DatadogInstrumentation+CRD+for+Workload-Scoped+Product+Enablement) to enable workload-scoped product configuration through a Kubernetes-native CRD. This PR builds the shared controller platform that all product handlers (Autodiscovery check delivery, APM SSI, etc.) will plug into.

Depends on: DataDog/datadog-operator#2962

### Describe how you validated your changes

Unit tests covering reconciliation dispatch, section-level event classification, leader-only status writes, `lastSeen` lifecycle, event deduplication, and status condition updates with a fake dynamic client.

#### CR status is updated on each create/update/delete event
<img width="696" height="173" alt="image" src="https://github.com/user-attachments/assets/37310f64-caf8-4167-b305-331a6ead76c9" />

<img width="793" height="610" alt="image" src="https://github.com/user-attachments/assets/5f884b70-a71e-4621-92b2-f5299fd62d68" />

Co-authored-by: mathew.estafanous <[email protected]>

…ok (#50428)

### What does this PR do?

Depends on #50206

Adds a validating admission webhook for `DatadogInstrumentation` CRs and refactors the `Webhook.Resources()` interface to support non-v1 API versions.

The validation webhook listens to CREATE/UPDATE events from `datadoginstrumentations.datadoghq.com` then runs three step validation:
1. **Unique targetRef per namespace**. Only one CR can target a given workload in a namespace. If a CR is submitted that matches an existing targetRef, it is rejected.

2. **Target compatibility.** For each handler where HasSection returns true, the controller calls SupportsTarget to verify the CR's targetRef kind is supported by that handler. For example, if a CR targets a Service but has spec.config.apm populated, the SSI handler rejects it because it only supports Deployments and StatefulSets.

3. **Product-specific validation.** Each relevant handler's Validate is called to check its own fields (check names, tracer version formats, etc.).

### Motivation

The validation webhook gives users immediate feedback on invalid CRs (duplicate targets, unsupported workload kinds, bad config) instead of silently ignoring bad configuration like annotations did.


#### Additional Notes

The `Webhook#Resources()` interface was refactored to return `[]common.WebhookResourceRule` to give each webhook full flexibility on the group/version/kind to intercept. Previously, `Resources()` used a group to many kinds map, and hardcoded the version to `v1`.

Unfortunately the DatadogInstrumentation CRD versioning isn't `v1` but `v1alpha1`, so CR events were never intercepted. A large in-place refactor had to be made to replace the hardcoded string with a configurable version.

### Describe how you validated your changes

Unit tests covering webhook validation (duplicate targetRef on create/update, target compatibility, product validation errors, multi-handler scenarios, fail-open on nil lister, section skipping) and the `WebhookResourceRule` refactor across existing webhook controller tests.

```bash
go test -tags kubeapiserver,test ./pkg/clusteragent/admission/validate/datadoginstrumentation/
```

#### Manual QA

1. Start the agent with instrumentation CRD + admission controller enabled
```yaml
platform:
  type: "minikube"
  name: "instrumentation-crd"
  reset: false
helm:
  versions:
    agent:
      build: {}
    cluster_agent:
      build: {}
    injector: "0.52.0"
  manifests:
    - path: "rbac.yaml"
      namespace: "system"
  config:
    datadog:
      operator:
        enabled: false
      clusterChecks:
        enabled: true
      kubelet:
        tlsVerify: false
    clusterAgent:
      enabled: true
      admissionController:
        enabled: true
      env:
        - name: DD_INSTRUMENTATION_CRD_CONTROLLER_ENABLED
          value: "true"
```
2. Attempt to deploy an invalid CR instance (ie. wrong targetRef kind `SomethingElse`)
```yaml
apiVersion: datadoghq.com/v1alpha1
kind: DatadogInstrumentation
metadata:
  name: example-instrumentation
  namespace: default
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Something-Else
    name: example-workload
  config:
    checks:
      - integration: redisdb
        containerImage:
          - redis
        initConfig: {}
        instances:
          - host: "%%host%%"
            port: 6379
            password: "12345678"
            tags:
              - service:redis
        logs:
          - type: file
            path: /var/log/redis/*.log
            source: redis
            service: redis
            tags:
              - service:redis
```
3. Validation webhook rejects CR create/update.
```
> admission webhook "datadog.webhook.datadog.instrumentation.validation" denied the request: handler "autodiscovery" does not support target kind "Something-Else"
```
4. Duplicate CR rejected
```
> admission webhook "datadog.webhook.datadog.instrumentation.validation" denied the request: DatadogInstrumentation "example-instrumentation" in namespace "default" already targets Deployment/example-workload
```

Co-authored-by: mathew.estafanous <[email protected]>

### What does this PR do?

Bump SGC on DCA to counteract increase from new DatadogInstrumentation CRD handler feature: #50206.

Note: no new external dependencies were included, just update of the Datadog Operator dep and code for the handlers


Co-authored-by: gabe.dossantos <[email protected]>