Windows self-hosted Docker readiness checks nonexistent `docker` service and does not enforce Windows engine

[wallstop]

Summary

The Windows self-hosted build workflow currently treats an SCM service named docker as the Docker readiness signal:

https://github.com/Ambiguous-Interactive/unity-builder/blob/c697872fe6ee7017957a9f002acc485058e00fbb/.github/workflows/build-tests-windows.yml#L155-L178

On the ELI-MACHINE runner targeted by [self-hosted, Windows, RAM-64GB], Docker Desktop is installed and its service is com.docker.service; there is no service named docker. A responsive Docker API can therefore be rejected before any build starts.

There is a second, distinct correctness requirement: these jobs run unity-builder's Windows container path (including windows-il2cpp, Windows mounts, and Windows isolation), so it is not sufficient for any Docker engine to answer. The live API must report OSType=windows. A healthy Linux Docker Desktop engine would pass a generic docker version check but cannot run these images.

Current behavior

The step:

1. calls Get-Service docker;
2. only probes docker version if that service exists and is running;
3. attempts Start-Service docker otherwise;
4. times out even when Docker Desktop's API is already healthy via com.docker.service;
5. does not verify that the selected Desktop engine is Windows.

This can block every matrix leg before the local action is exercised, or admit the wrong Docker engine if the service-name problem is worked around without checking engine type.

Expected behavior

Use Docker's live API as the health authority, not the legacy/service-name heuristic. For this workflow, readiness should require:

docker info --format '{{.OSType}}'

to succeed and return exactly windows (case-insensitive), with bounded retries.

com.docker.service may be included in diagnostics or used by an explicit recovery procedure, but SCM state alone must not be treated as Docker API health.

If the API responds with linux, fail promptly with an explicit wrong-engine message (or invoke the repository/runner's supported Windows-engine reconciliation before retrying). Do not report that as a generic daemon timeout.

Suggested diagnostics

On failure, include bounded output for:

• expected engine: windows
• actual docker info .OSType value, if reachable
• docker context show
• docker desktop engine ls --format json
• status of com.docker.service
• final docker version stderr/exit code

Avoid using the legacy docker_engine alias or service state as the sole authority; Docker Desktop can expose engine-specific endpoints and the selected API can differ from Desktop's intended engine during a split-engine incident.

Acceptance tests

Please cover at least:

• no docker service, com.docker.service running, API reachable with OSType=windows → pass;
• API reachable with OSType=linux → fail with an explicit expected/actual engine diagnostic;
• API unavailable → bounded retry and actionable diagnostics;
• the readiness path never attempts Start-Service docker;
• the matrix's Windows-container action is not invoked until Windows engine identity is verified.

Host evidence

On the affected runner, Get-Service docker returns nothing while com.docker.service is Running/Automatic. During investigation the selected Docker Desktop engine was Linux and docker version succeeded, demonstrating why API liveness and required engine identity must be checked separately.

[wallstop]

Watchdog-side admission is now job-scoped. Please add job-level DOCKER_DESKTOP_ENGINE_REQUIRED: windows to buildForAllPlatformsWindows. The synchronous pre-job hook will then verify the explicit Windows Desktop pipe, live OSType=windows, successful container queries, and zero pre-existing containers before any workflow step runs. The watchdog carries a compatibility mapping for this exact existing job, but the explicit contract should live with the workflow so future routing remains self-describing. This complements the API readiness fix in the issue body; it does not replace the bounded docker info / OSType check in the workflow.

[wallstop]

Correction to my preceding comment: after checking the current GitHub runner hook implementation, job-level env is not a supported/reliable transport into the pre-job hook process. Do not add DOCKER_DESKTOP_ENGINE_REQUIRED. The watchdog instead uses its administrator-protected DockerRequiredJobs mapping for this exact repository/job. The workflow change requested here remains the bounded Docker API readiness check that requires OSType=windows; the host-side mapping supplies the independent pre-step admission boundary.