fix: default to unix scheme when DOCKER_HOST is a filesystem path

[amarkdotdev]

Description

When DOCKER_HOST is set to a filesystem path without a unix:// prefix (e.g. DOCKER_HOST=/var/run/docker.sock), the CLI produces a confusing error:

Cannot connect to the Docker daemon at tcp://localhost:2375/var/run/docker.sock. Is the docker daemon running?

The path gets misinterpreted as a TCP address because parseDockerDaemonHost defaults to the tcp protocol when no scheme is present.

Root cause

In opts/hosts.go, parseDockerDaemonHost splits on :// and defaults any scheme-less address to tcp:

if !hasProto && proto != "" {
    host = proto
    proto = "tcp"  // always defaults to tcp
}

Fix

When the scheme-less address starts with / or ./ (i.e. it's clearly a filesystem path), default to unix instead of tcp. This matches the user's intent and either connects successfully or produces a clear, relevant error.

Before:

$ DOCKER_HOST=/var/run/docker.sock docker version
Cannot connect to the Docker daemon at tcp://localhost:2375/var/run/docker.sock.

After:

$ DOCKER_HOST=/var/run/docker.sock docker version
# connects normally (equivalent to unix:///var/run/docker.sock)

Testing

• Added test cases to TestParseDockerDaemonHost for /var/run/docker.sock and ./run/docker.sock
• Verified the parsing logic with a standalone reproduction covering path, hostname, and explicit-scheme inputs
• Existing tcp and explicit unix:// cases remain unchanged

Fixes #5846