[bug] Volume name collisions in PodSpec when multiple containers share target paths

[ShantKhatri]

Describe the bug
When generating Kubernetes PodSpec manifests, Volumes are defined at the Pod level and require strictly unique names. Currently, score-k8s derives volume names exclusively from the target path hash or a global index, completely omitting the container identity.

This generates invalid Kubernetes manifests with duplicate volume names in two distinct scenarios:

1. Identical Target Paths Across Containers: If Container A and Container B both mount a file (or volume) to /etc/config.yaml, score-k8s attempts to create a Pod volume named file-<hash> for both containers.
2. Projected Volume Collisions: collapseVolumeMounts generates names like proj-vol-0 using an index that resets per container. If multiple containers require a projected volume, score-k8s defines proj-vol-0 for each of them.

Kubernetes rejects PodSpecs containing duplicate volume names.

To Reproduce
Steps to reproduce the behavior:

1. Create a score.yaml with two containers that inject a file to the same target path:

apiVersion: score.dev/v1b1
metadata:
  name: collision-test
containers:
  web:
    image: nginx
    files:
      /etc/config.yaml:
        content: "web config"
  worker:
    image: busybox
    files:
      /etc/config.yaml:
        content: "worker config"

2. Run score-k8s init
3. Run score-k8s generate score.yaml
4. Inspect the generated deployment manifest and observe the duplicate file-<hash> entries under .spec.template.spec.volumes.

Volume names generated in the PodSpec should be guaranteed unique across the entire Pod. This can be achieved by including the container name context when computing the volume name or hash, ensuring no conflicts exist when assembling the final Pod volumes list.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Ubuntu
• Version 24.04.4

Additional context
This was discovered while investigating a different file mount collision issue(score-spec/score-compose#506) in score-compose. Since score-k8s relies on hashing the target path to adhere to the 63 character Kubernetes naming limit, incorporating the container identity into that hash generation is the most robust and idiomatic fix to keep names within limits while ensuring uniqueness.

[ShantKhatri]

Hi @mathieu-benoit, As discussed in score-spec/score-compose#506, regarding handling collision logic natively per repository since Kubernetes requires strict hashing to stay under the 63 character limit.

I am opening this as a separate issue because the behavior here is different. The bug in Compose happened within a single container. Here in score-k8s, the collision occurs across multiple containers sharing the same target paths.

The fix is straightforward: we just need to namespace the volume generation logic by the container identity. I have a fix running locally that injects the container name into the target hashes and projected volume indices to guarantee unique PodSpec names. I will open a PR for this shortly if this looks good to you.