[Feature] NAP support for Pod Sandboxing

**Is your feature request related to a problem?**
AKS Pod Sandboxing (Kata Containers) isn't available when nodes are provisioned by Karpenter (node auto-provisioning). There's no way to declare that a Karpenter NodeClass should provision Kata-capable nodes, and no scale-up path - a pending pod with runtimeClassName: kata-vm-isolation won't trigger Karpenter to bring up a suitable node.

**Describe the solution you'd like**

A workloadRuntime field on AKSNodeClass:
```
spec:
imageFamily: AzureLinux
workloadRuntime: KataVmIsolation # OCIContainer (default) | KataVmIsolation | KataMshvVmIsolation (legacy)
```
This means:
- OCIContainer default → backward compatible.
- KataVmIsolation provisions nodes with the Kata host stack.
- Karpenter advertises the kubernetes.azure.com/kata-vm-isolation node labels on Kata-capable SKUs, so the RuntimeClass admission controller's injected nodeSelector + 600Mi overhead drive scale-up and bin-packing - no pod nodeSelector needed, just runtimeClassName.
- Guardrails: requires imageFamily: AzureLinux (CEL) and a gen-2, nested-virt SKU (instance-type filtering). Gated behind ENABLE_KATA_POD_SANDBOXING=true + an AKS Machine API provision mode.

**Describe alternatives you've considered**

- Inferring Kata from a pod's rue host stack is chosen atprovisioning time.
- Hand-labelling nodes / pod nodeSelector — brittle, and doesn't inform Karpenter's scale-up.
- Keeping Kata on managed agent ating node lifecycle underKarpenter.

**Additional context**

Implemented in Azure/karpenter-provider-azure#1721 (CRD/CEL validation, SKU filtering, node-label advertisement, opt-in flag, example, unit + e2e tests).

If this merges, can the ENABLE_KATA_POD_SANDBOXING be enabled for my clusters out of band by support?