Add full e2e CI lane for BuildKit sidecar + Radius.Compute/containerImages

[willdavsmith]

Background

The new Radius.Compute/containerImages resource type (resource-types-contrib#151) and the BuildKit sidecar in the dynamic-rp chart (radius#11882) currently rely on a separate demo repository (https://github.com/willdavsmith/radius-containerimagetype-demo) for end-to-end CI validation: rootless BuildKit, multi-arch build, registry push, digest output flowing into a Radius.Compute/containers resource.

That demo repo will continue to exist as the live e2e proof, but we should land an upstream e2e lane that exercises the same path against main.

Scope

Add a workflow under .github/workflows/ that:

1. Installs Radius with dynamicrp.buildkit.enabled=true against a kind cluster.
2. Provisions registry credentials (a CI-scoped GHCR robot, an in-cluster registry, or similar).
3. Registers the Compute/containerImages recipe pointing at the merged contrib version (or a tagged release).
4. Deploys a containerImages + containers app from a small fixture.
5. Asserts the produced image is reachable, has the expected manifest, and is pulled successfully by the container.

Open questions

• Self-hosted runner with a registry vs. ghcr.io with a CI token.
• Multi-arch coverage (the demo repo proves linux/amd64 + linux/arm64) — kind cluster needs binfmt or a self-hosted arm runner.
• Where to live (existing e2e workflow vs. new dedicated lane).

Out of scope (already shipped)

• Helm-unittest coverage of the chart sidecar shape.
• terraform validate of the recipe.