chore(security): VEX three new compose CVE findings and correct dependency comment (#1201)

Trivy reported three new advisories against the compose binary today:

- CVE-2026-41568 (docker cp symlink-swap empty-file creation, sibling of
  CVE-2026-42306)
- CVE-2026-33997 (Moby plugin install privilege bypass)
- GHSA-pmwq-pjrm-6p5r (in-toto-golang glob-negation operator mismatch)

All three are daemon-side or supply-chain attestation code paths that
compose only embeds as client-side libraries. Sencho invokes compose
exclusively for up/down/ps against user-authored compose files, never
runs daemon endpoints, never performs plugin installation, and never
verifies in-toto attestations. Each gets a not_affected statement with
a full impact rationale; bump version 7 to 8 and last_updated to today.

Also correct the compose-builder comment in Dockerfile. The previous
text claimed compose v5.1.3 "eliminated CVE-2026-34040 and CVE-2026-33997
at the dependency level" by moving docker/docker to an indirect dep.
That is wrong: the module is still pulled via buildkit and other
transitive paths, the CVEs still appear in scans, and they are tracked
in the VEX file rather than eliminated. The corrected comment points
the reader at the VEX file as the source of truth for these findings.

Dockerfile

@@ -135,9 +135,15 @@ RUN cp vendor.mod go.mod && cp vendor.sum go.sum && \
 
 # Stage 4b: Build Docker Compose from source against Go 1.26.3
 #
-# Compose v5.1.3 removed the direct dependency on github.com/docker/docker
-# (replaced by moby/moby/api + moby/moby/client), eliminating CVE-2026-34040
-# and CVE-2026-33997 at the dependency level. Rebuilding with the patched Go
+# Compose v5.1.3 moved github.com/docker/docker from a direct require to an
+# indirect dep (the direct surface is now moby/moby/api + moby/moby/client),
+# but the docker/docker module is still pulled into the binary via buildkit
+# and other transitive paths. Several daemon-side CVEs against docker/docker
+# v28.5.2 (CVE-2026-34040, CVE-2026-33997, CVE-2026-41567, CVE-2026-41568,
+# CVE-2026-42306) therefore still appear in scans of the compose binary;
+# they are tracked as not_affected in security/vex/sencho.openvex.json
+# because compose is the client and the vulnerable code paths are reached
+# only by Docker Engine the daemon. Rebuilding with the patched Go
 # toolchain eliminates Go stdlib CVEs from the binary's SBOM.
 #
 # Compose v5.1.3 still bundles otel/sdk v1.42.0 transitively via buildkit