feat(up): stamp com.docker.compose project/service labels on containers

[DonsWayo]

container-compose up names containers <project>-<service> but writes no labels
(container inspect → labels: {}). External tools (GUIs, dashboards, scripts) that want to
group a stack's containers are forced to guess from the name prefix, which mis-groups
unrelated containers that merely share a prefix (e.g. qa-web + qa-cache).

This stamps the de-facto-standard Docker Compose labels on each container at creation:

• com.docker.compose.project=<project>
• com.docker.compose.service=<service>

so any tool can group a stack reliably via labels. No behavior change otherwise —
down/ps continue to work by name.

Diff

One file, +6 in ComposeUp.swift, right after --name is appended:

runCommandArgs.append(contentsOf: ["--label", "com.docker.compose.project=\(projectName)"])
runCommandArgs.append(contentsOf: ["--label", "com.docker.compose.service=\(serviceName)"])

Verified (macOS 26, container 1.0.0)

$ container-compose up -d --file docker-compose.yml   # name: lblproj, service: one
$ container inspect lblproj-one | jq .configuration.labels
{
  "com.docker.compose.project": "lblproj",
  "com.docker.compose.service": "one"
}
$ container-compose down --file docker-compose.yml     # tears down unchanged

Built from source and run against a real daemon; swift build clean.

Notes

• Composes cleanly with feat(commands): add -p/--project-name flag and docker compose projec name resolution #104 (project-name flag) — this just uses the resolved projectName.
• Label key choice: com.docker.compose.* for broad tool interoperability. Happy to switch
  to a project-specific namespace if you'd prefer.
• Could extend to label the project network/volumes once per-project isolation lands.

[Cyb3rDudu]

Looks good - correct mechanism, right label namespace for tool interop, and verified working. We can add a dynamic test (up → assert both labels present via inspect) so this doesn't silently regress; (2) when service.labels support lands later, make sure these two compose labels are applied last / take precedence over a user setting the same key. Nice that it composes cleanly with #104 and #113. consider folding this into the existing labels: pass-through pattern (see the commented-out network-labels block) for consistency and to also pick up user-defined service labels.

[Cyb3rDudu]

Looks good — generalized label stamping + test, builds clean, signed.