Move the AI worker from docker/docker to the moby/moby client

[rickstaa]

The last 5 open Dependabot alerts are on github.com/docker/docker and github.com/docker/cli, three high and two medium. No version bump closes them: the Docker Go module moved to github.com/moby/moby/client and github.com/moby/moby/api after 28.x, and docker/cli 29 only builds against those. Part of #4051.

Exposure today: none. go list -deps ./cmd/livepeer links only docker/client, docker/api/types/*, errdefs, pkg/jsonmessage and cli/opts. No daemon package and no CLI plugin loader is compiled in, and the copy and archive client APIs the alerts describe are never called anywhere in the repo. All five bugs live in code we do not ship.

Scope. ai/worker/docker.go and its test. The worker uses Docker through a local DockerClient interface with eight methods: ContainerCreate, ContainerInspect, ContainerList, ContainerRemove, ContainerStart, ContainerStop, ImageInspectWithRaw, ImagePull. Around thirty type uses across eleven imports.

Work

1. Land after Remove the deprecated ai-runner batch pipelines #4036, which trims the same files.
2. Add the moby client and api modules at the versions docker/cli 29 vendors, bump docker/cli to 29, drop docker/docker and go-connections if nothing else needs them.
3. Rewrite imports and renamed types, check the eight calls against the moby signatures, update the mock.
4. Remove the docker/cli ignore from .github/dependabot.yaml.
5. Verify on a GPU orchestrator end to end: pull, create with GPU devices and mounts, start, health check, stop, remove.

Risk of doing it. Contained to AI runner container management; failures are loud, not subtle. Same Docker API over the same socket, so no operator Docker upgrade. Ship with a canary orchestrator, not as a hotfix.

Risk of not doing it.

• The daemon bugs are real on an orchestrator's host, but they are fixed by the operator's Docker installation, not by our go.mod. Bumping the module would protect nobody.
• If code is later added that calls the copy or archive APIs, or the CLI plugin loader, the exposure becomes real and nothing re-flags it, because the alerts are already known-open.
• Five permanently open alerts, three of them high, erode attention on the security page.

@j0sh Meaning it might not even be worth it if we deprecate the software for a more minimal modular stack soon.

[j0sh]

How bad are the docker alerts for us? At this point, streamdiffusion not getting much attention and may be sunset sooner rather than later, so I'd prefer not to make any significant changes that will require us to re-validate the stack, including porting it over to the live runner.