docker version probe reads the CLI client version, not the Desktop Engine version, so a current host still fails the floor

[ptr727]

The docker floor's own rationale (spec/host-tools.json:11) says "the probe reads the engine version, not the Desktop application version winget tracks separately, so the floor is written against the number the probe actually sees." That claim does not hold on a WSL host where the docker CLI on PATH is a separate client binary from Docker Desktop's Engine.

host_gate.py's probe for docker, declared generically at spec/host-tools.json:8 as ["docker", "--version"], and install-tools.sh's docker_version() (host-setup/linux/install-tools.sh:549-552) both parse the Docker version X.Y.Z line, which is docker's own client version banner, not the engine it talks to.

What this looks like on a current host

Docker Desktop reports itself up to date. docker --version and docker version on the same host disagree by a full minor line:

$ docker --version
Docker version 29.1.3, build 29.1.3-0ubuntu3~25.10.1

$ docker version
...
Server: Docker Desktop 4.86.0 (236216)
 Engine:
  Version:          29.7.2

The client binary on PATH here is packaged separately from Desktop's own bundled CLI, its build string, 29.1.3-0ubuntu3~25.10.1, is an Ubuntu package revision, not a Desktop release artifact, and it talks to Desktop's daemon over the same WSL-integration socket. host_gate.py and install-tools.sh --report both read the client's 29.1.3 and fail the 29.6.2 floor from issue #695, while the Engine actually running (29.7.2) clears it comfortably, and Desktop itself (4.86.0) is newer than the 4.85.0 the floor was anchored to.

Shapes that would close it

Not a recommendation, just what seems available:

1. Read the Engine version instead, for example docker version --format '{{.Server.Version}}' (or the Server: block of docker version), inside a WSL distribution specifically, since that is what Desktop's own update cadence actually governs. The native (non-WSL) install path can keep reading docker --version, since there the client and the docker-ce engine are the same package.
2. Drop the floor's engine-version claim if the client version is kept as the probe deliberately, and reword spec/host-tools.json:11 so a future reader does not rely on the client and the Engine tracking together, which this host shows they do not.

Found while testing host-setup/ and scripts/host_gate.py on an Ubuntu 25.10 WSL2 host under Docker Desktop 4.86.0.

[ptr727]

Fixed in #753, squash-merged to develop as 5c6decf. The probe list is now docker version --format '{{.Server.Version}}' first and docker --version as the fallback, with install-tools.sh's docker_version() reading the same two in the same order, per shape 1. The engine reading applies on every platform rather than only inside WSL, since the CLI and the engine are one package on a native install and spec/host-tools.json has no way to express a WSL-conditional probe. The floor's why and docs/host-setup.md no longer claim the client and the engine track together. Closing here rather than waiting on the develop to main promotion, which is what would have closed it automatically.