feat: cache managed Cilium dns-proxy images in Linux VHDs

**Is your feature request related to a problem?/Why is this needed**

Managed Cilium deploys
`mcr.microsoft.com/containernetworking/cilium/dns-proxy:` in the
Linux-only `acns-security-agent` DaemonSet. The image is not currently listed
in AgentBaker `parts/common/components.json`, so every fresh node requires a
successful runtime MCR pull before this ACNS DNS component can start.

Fleet investigation found repeated `dns-proxy` image-pull failures during a
registry transport anomaly. A separate large node-replacement wave also
confirmed that each new node performed the network pull, adding avoidable
registry demand and startup variance.

This image is not part of the Cilium CNI installation init chain. The request
is therefore an ACNS availability and deterministic-startup improvement, not a
claim that `dns-proxy` blocks core CNI initialization.

**Describe the solution you'd like in detail**

Add `mcr.microsoft.com/containernetworking/cilium/dns-proxy:*` to
`parts/common/components.json`, following the current-and-previous version
pattern already used by `cilium-distroless` and `cilium-distroless-init`.

Proposed initial entries:

- Cilium 1.18: `v1.18.12-260811` and `v1.18.11-260622`
- Cilium 1.19: `v1.19.6-260811` and `v1.19.5-260714`

All four tags are published for Linux amd64 and arm64. `windowsVersions`
should remain empty.

The final versions should be checked against the exact tags rendered by the
AKS RP/chart. AgentBaker should preserve both current and previous tags while
they coexist in the managed fleet.

Acceptance criteria:

1. A fresh amd64 and arm64 node from the target VHD already contains the exact
managed `dns-proxy` image before `acns-security-agent` starts.
2. Kubelet reports the image already present and does not issue a registry
`Pulling` event for that tag.
3. Current and previous managed tags remain cached during version transitions.
4. A large replacement-wave test confirms there is no `dns-proxy`
`ErrImagePull` or `ImagePullBackOff`.
5. Release validation detects an RP/chart tag that is absent from the VHD
manifest.

**Describe alternatives you've considered**

- Runtime retries leave node startup dependent on registry and network
availability.
- Karpenter or Cluster Autoscaler pacing reduces concurrency but does not
remove the dependency.
- A local mirror adds another serving path and operational dependency.
- Monitoring detects delayed startup but does not prevent it.

VHD caching is the existing AgentBaker mechanism used by neighbouring managed
Cilium images and removes the pull from the fresh-node critical path.

**Additional context**

Related work: #9325 adds `azure-iptables-monitor` to the Linux VHD cache for
the separate CNI-bootstrap path.

Start with parts/common/components.json and compare the current-and-previous cilium-distroless entries, then inspect the AgentBaker VHD and release-validation paths that consume this manifest. Verify the final AKS RP/chart tags for Cilium 1.18 and 1.19, keep Linux amd64 and arm64 coverage with no Windows entries, and confirm fresh-node validation satisfies the listed caching and pull-event criteria.

Written by the indexing model from the issue text.