ci: run full test suite on Windows

[Sayt-0]

Summary

• run the full Go test suite natively on windows-latest as a blocking CI gate
• use the same Task-based test entry point on Windows and Linux
• fix the Windows-specific product and test issues exposed by the new gate

Why this is useful

The project publishes Windows binaries and contains Windows-specific implementations for file locking, atomic writes, paths, sockets, processes, and executable handling. Cross-compilation proves that these implementations compile, but only a native Windows runner exercises their real filesystem and process semantics.

The initial observational run exposed failures in 36 packages. The fixes in this PR address those failures rather than hiding them behind continue-on-error, including:

• Windows executable installation and .exe resolution
• standard LSP file:// URI handling
• portable HOME, path, shell, PowerShell, file-mode, and symlink behavior
• deterministic resource cleanup for SQLite databases, listeners, and os.Root handles
• Windows drag-and-drop path parsing and cassette path normalization
• Windows-safe content-store filenames

CI design

Area	Behavior
Go packages	Full suite in one blocking native Windows step
Test entry point	task test, matching Linux and loading .env.test
Windows runner setup	One checkout, one Go setup, and one Task setup
Binary and Docker E2E	Not included in this change
Timeout	30 minutes

Validation

Check	Result
Native Windows full suite	pass, 13m37s
Linux build and tests	pass, 8m07s
Lint and workflow lint	pass
Linux amd64 image build	pass, 4m37s
Linux arm64 image build	pass, 3m39s
License check	pass

Latest fully green run: https://github.com/docker/docker-agent/actions/runs/30616302947

The Windows runner reports GOOS=windows, GOARCH=amd64, CGO_ENABLED=1, and CC=gcc.

[Sayt-0]

@ronan-thibaut-glitch could you try on your computer ?

[aheritier]

🤖 Automated implementer agent — this comment was posted by the implementer bot from Docker Agentic Platform, not by a human developer

Replying to @aheritier's concern in #3866 (comment):

Good catch to flag — but this concern is actually unfounded for a couple of reasons.

pkg/paths/paths.go is not modified by this PR at all. It already called os.UserHomeDir() on main and this PR leaves it untouched.

Go's os.UserHomeDir() on Windows does not use $HOME. On Windows the implementation reads %USERPROFILE% (falling back to HOMEDRIVE + HOMEPATH), which is exactly what was being used before. The Unix-style $HOME lookup only applies on Linux/macOS — so there is no change from USERPROFILE to HOME here.

The new test TestGetHomeDirUsesPlatformNativeHome added by this PR is a regression guard: it deliberately sets HOME and USERPROFILE to different directories and asserts that GetHomeDir() always delegates to os.UserHomeDir(), preserving the platform-native path. Windows users will continue to find their settings under %USERPROFILE%, exactly as before.