Add support for WSL container runtime

Nobody has claimed this yet.

WSL now supports its own container runtime and CLI (`wslc`, https://learn.microsoft.com/en-us/windows/wsl/wsl-container).

We should support it on par with existing Docker and Podman runtimes.

## Current WSLC support gaps

Track remaining gaps for supporting `wslc` as a DCP container runtime, measured against the capabilities DCP currently uses from Docker and Podman.

## Blocking gaps

- [x] **Tar/archive-based copy into containers**
- microsoft/WSL#40835
- Current `wslc` does not have `container cp` support sufficient for DCP `CreateFiles`.
- DCP impact: blocks streaming generated tar contents into a created container.

- [x] **Per-network aliases / DNS alias parity**
- microsoft/WSL#40970
- microsoft/WSL#40972
- Current `wslc` supports `--network` and `--network-alias`, but aliases are not scoped inside each `--network` value and current alias behavior is limited to the single-user-network path.
- DCP impact: blocks full Docker/Podman-style service discovery when a container joins multiple networks with different aliases.

## Gaps requiring workarounds or degraded functionality

- [x] **Runtime events/watch support**
- microsoft/WSL#40971
- Current `wslc` does not expose a Docker/Podman-style event stream.
- DCP impact: container/network watches would require polling or another WSLC-specific strategy. Network watch support may still need separate validation even after container events land.

- [x] **Post-create network connect/disconnect**
- https://github.com/microsoft/WSL/pull/41011
- Current `wslc network` supports create/remove/inspect/list/prune, but not `connect` or `disconnect`.
- DCP impact: dynamic network attach/detach is not directly implementable. This is less important if DCP attaches all required networks during container creation.

- [ ] **Pull policy semantics during create/run**
- Current `wslc container run` has pull support commented out and does not expose Docker/Podman-style `--pull=always|missing|never`.
- DCP impact: `PullPolicyAlways` / `PullPolicyNever` would need to be approximated with explicit image inspect/pull behavior before create/run.

- [ ] **Build secrets and platform selection**
- Current `wslc image build` supports path, build args, pull, target, Dockerfile, labels, no-cache, tags, and verbose output.
- It does not appear to expose build secrets or build platform.
- DCP impact: builds using `ContainerBuildContext.Secrets` or `Platform` would be degraded or unsupported.

- [x] **Healthcheck configuration/status**
- https://github.com/microsoft/WSL/pull/41012
- No Docker/Podman-style healthcheck configuration or health status equivalent was identified.
- DCP impact: may block tests or future runtime behavior if DCP requires `CreateContainerOptions.Healthcheck`.

- [ ] **Stable host callback name**
- No obvious `host.docker.internal`, `host.containers.internal`, `host-gateway`, or `--add-host` equivalent was identified in the current `wslc` CLI surface.
- DCP impact: may affect `ContainerHost()` and host callback/proxy paths that need a stable host name from inside containers.

## Honorable mentions

- [ ] **Registry proxy/mirror configuration**
- microsoft/WSL#40945
- microsoft/WSL#40981
- microsoft/WSL#40951
- DCP impact: not a direct orchestrator interface gap, but relevant for reliable `PullImage` behavior in enterprise or restricted-network environments.

Start by reviewing DCP's existing Docker and Podman runtime integrations and the wslc CLI capabilities listed in this issue. Compare each unchecked gap with the runtime behavior DCP currently requires; done means agreeing on a scoped implementation or documented limitation for the remaining wslc gaps.

Written by the indexing model from the issue text.