wslc: switch image build from docker build to docker buildx build

[beena352]

Summary of the Pull Request

Change the command wslc runs inside the container VM for wslc image build from docker build to docker buildx build. Zero behavior change, same flags, same context mount, same rawjson output parsed by the existing BuildKitSolveStatus parser.
This is a preparatory PR. It unblocks a follow-up that will enforce the WSLContainerRegistryAllowlist group policy on image builds. Classic docker build cannot honor a BuildKit source policy; docker buildx build can. Splitting the invocation swap from the policy logic keeps both PRs small and gives a clean bisect point.

PR Checklist

• Closes: Link to issue #xxx
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated if needed and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated if needed
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Why we're doing this
The WSLContainerRegistryAllowlist group policy (added in #40466) lists which registries wslc may talk to. PullImage and PushImage enforce it per-call, but BuildImage couldn't, a Dockerfile's FROMs resolve inside dockerd via ARGs, COPY --from=, --build-context, etc., which we can't reliably parse client-side. So #40466 took the strict-secure default: whenever the allowlist is configured, every wslc image build is refused outright. That leaves enterprise customers with the policy enabled unable to build images at all, even from an allowed registry.
The follow-up PR fixes that by pushing enforcement into BuildKit itself, via its per-invocation source-policy JSON (evaluated after ARG substitution, before any registry request). The catch: classic docker build in moby v25.0.7 silently drops the SourcePolicy field, no CLI flag or env var fills it in. docker buildx build with the default docker driver speaks BuildKit gRPC directly, so SourcePolicy (via EXPERIMENTAL_BUILDKIT_SOURCE_POLICY) travels intact.
This PR makes wslc image build go through buildx so the follow-up can enforce the policy. That's it.

Zero-behavior-change verification
Argv shape: buildx accepts every flag BuildImage passes (--progress=rawjson, -f -, -t, --build-arg, --label, --target, --no-cache, --pull) plus the mounted context path - unchanged.
Rawjson stream: all 14 fields the C++ parser destructures (vertexes, statuses, logs, digest, name, started, completed, error, id, vertex, current, total, data, stream) parse identically.
VM availability: buildx already ships at /usr/libexec/docker/cli-plugins/docker-buildx (BuildKit v0.12.5) - no new dependency.

Validation Steps Performed

[Copilot]

Pull request overview

This PR updates WSLC session image builds to invoke BuildKit via docker buildx build (instead of classic docker build) inside the container VM, as a preparatory step for enforcing registry allowlist policy via BuildKit source-policy in a follow-up change.

Changes:

• Switched the in-VM image build command from docker build to docker buildx build while preserving --progress=rawjson and the existing argument construction.

[benhillis]

The direct Buildx invocation loses Docker CLI forwarding behavior that guarantees the result is loaded into the local image store.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

src/windows/wslcsession/WSLCSession.cpp:917

• docker buildx build does not necessarily load the resulting image into the local Docker image store unless an output is specified (e.g., --load/--push). If buildx ends up using the docker-container driver (common when a non-default builder is active), this invocation can succeed but leave no image/tag available afterward, which would be a behavior change vs docker build. Add --load (or explicitly select a docker driver/builder) to preserve the previous semantics that the built image is usable immediately via the daemon.

    std::vector<std::string> buildArgs{"/usr/bin/docker", "buildx", "build", "--progress=rawjson"};

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.