fix: name selected Docker connection in DMR transport errors

[dgageot]

Since #4481, DMR requests over an explicitly selected Docker connection dial through a subprocess started via commandconn.New for docker system dial-stdio. That subprocess can exit quickly, and the resulting net.Conn Read/Write calls then surface as a bare closed or broken pipe error with no indication of which Docker connection (--host, --context, etc.) was in use. TestDMRDockerConnectionErrorNamesEngine catches this on Linux but is flaky because of the race between the subprocess exiting and the first read, which also made it fail intermittently under #4490 even though that PR never touched this code path.

This adds a dockerTransport that wraps *http.Transport and, on a failed RoundTrip, returns a *net.OpError naming the selected connection's args while preserving errors.Is matching, Timeout/Temporary, and CloseIdleConnections. The wrapper is only used when a Docker connection was explicitly selected; the default unix-socket path is untouched. resolve_test.go adds a deterministic table of dial errors, closed/broken pipes, EOF, and context cancellation/deadline so the error-naming behavior no longer depends on subprocess timing.

Validated with task build, task test, and task lint, plus targeted repeats of the new and existing DMR tests (go test -race ./pkg/model/provider/dmr/dmrmodels -count=20, and Linux-only repeats of TestDMRDockerConnectionErrorNamesEngine and the new deterministic test) to confirm no remaining flakiness.