go.mod pins vulnerable docker/containerd modules; two open Dependabot PRs clear most findings

Hi, and thanks for maintaining this project.

Running `trivy fs .` (v0.69.3, vulnerability DB as of 2026-09-07) against the repo root reports findings on go.mod's indirect docker/containerd pins:

| Pinned module | Findings | Fixed in |
|---|---|---|
| `github.com/containerd/containerd v1.7.13` | CVE-2024-25621 (HIGH) + several MEDIUM | 1.7.33 |
| `github.com/docker/cli v25.0.3+incompatible` | CVE-2025-15558 (HIGH) | 29.2.0 |
| `github.com/docker/docker v27.1.1+incompatible` | CVE-2026-41567, CVE-2026-42306 (HIGH); CVE-2026-33997, CVE-2026-41568 (MEDIUM) | no fixed release on this module path |

Anyone importing container-structure-test as a Go library inherits these into their SBOM and scan results, so the go.mod pins have some reach beyond the CLI itself.

The good news is that two of the three rows are already solved by open Dependabot PRs:

- #562 (containerd 1.7.13 → 1.7.33) clears the containerd findings.
- #550 (docker/cli 25.0.3 → 29.2.0) clears CVE-2025-15558.

I can confirm both bumps compile and pass tests against the library import surface in a downstream consumer, so merging those two looks like a quick win.

`github.com/docker/docker` is the remaining gap, and it is a migration rather than a bump: the module path is deprecated as of Engine v29, its highest tag (v28.5.2+incompatible) is still affected by the four CVEs above (so #506 would not remediate them), and the fixes ship only on the maintained moby v2 module line.

Filing this mainly to make the picture easy to act on.

Start with go.mod, then inspect Dependabot PRs #562 and #550 and run the reported `trivy fs .` scan to verify their impact. Review issue #506 and the docker/docker module-path details before assessing the remaining migration. Done means the two dependency updates are validated and the remaining vulnerability gap has a documented path forward.

Written by the indexing model from the issue text.