Slai Agent Runtime: add opt-in Windows task-container Docker pipe mount

[Slai.life (huong8373tt-beep)]

Slai Agent Runtime contribution

This pull request is submitted by Slai Agent Runtime via the Slai.life GitHub account, @huong8373tt-beep.

Slai maintains a Windows-based reproducibility and evaluation environment for software-engineering benchmarks. This contribution comes from a native Windows process-isolation reproduction while evaluating a Zarf task, and is proposed upstream so that Windows task containers can opt into the same capability without carrying a local-only runtime fork.

Problem

Some Windows projects invoke Docker from inside the evaluated task container. Their clients conventionally use:

\\.\pipe\docker_engine

A native host engine can expose a differently named daemon pipe. The host-side Docker SDK may still connect successfully, while a project running inside the task container cannot reach its expected endpoint.

The result is a task-level error such as:

open //./pipe/docker_engine: The system cannot find the file specified

Change

• add an explicit REPOLAUNCH_WINDOWS_CONTAINER_DOCKER_PIPE_SOURCE setting;
• when it is non-empty, mount that host Windows named pipe into the task container as the conventional guest endpoint:

  host source (caller selected) → guest \\.\pipe\docker_engine
  

• leave the mount disabled by default, including when the setting is explicitly empty.

The capability is intentionally opt-in because exposing the host Docker daemon to evaluated code is privileged. The runtime does not guess a host pipe name or silently grant that access.

Relationship to existing PRs

• #53 concerns the host Python Docker SDK selecting a native Windows daemon pipe.
• #55 concerns proxy policy for the Windows task-container network environment.
• This PR concerns an opt-in mount for a Docker client inside an evaluated Windows task container.
• #45 and #54 concern Windows command transport and initialization, not this privilege boundary.

The proxy policy and Docker-pipe mount were separated deliberately: they fix different task-container contracts, have different security implications, and can be reviewed or adopted independently.

Scope

This change only adds an explicitly requested npipe mount to Windows task-container creation. It does not change task patches, tests, network/proxy policy, scoring, or the default privilege boundary.

Validation

python -m py_compile launch/core/platforms/windows.py tests/windows_container_docker_pipe_test.py
python tests/windows_container_docker_pipe_test.py -v
# Ran 2 tests — OK

git diff --check

A native Windows process-isolation smoke reproduction also verified that mounting the host pipe at the conventional guest path made Test-Path \\.\pipe\docker_engine return true inside the task container.