NVCA creates one shared ComputeDomain instead of one per NVLink domain index

Describe the bug

When NVCA allocates a ComputeDomain for a function's Pods on an
NVLink-optimized cluster, it creates a single, fixed-name ComputeDomain
(and backing channel ResourceClaimTemplate) for the whole function,
regardless of how many distinct
dra.nvcf.nvidia.io/required-nvlink-domain-index values are present
across that function's Pods.

A ComputeDomain represents a single IMEX domain. Pods that set
different required-nvlink-domain-index values are, by definition,
meant to be scheduled into different, independent NVLink domains (this
is exactly what the annotation's existing pod-affinity behavior already
enforces). Pointing every index group at the same shared ComputeDomain
object is inconsistent with that intent.

Steps or code to reproduce bug

1. Enable the NVLinkOptimized cluster attribute.
2. Deploy a Helm function whose Pods set two or more distinct
   dra.nvcf.nvidia.io/required-nvlink-domain-index values (for example,
   "0" and "1") to form separate logical NVLink domain groups.
3. Observe that NVCA creates only one ComputeDomain object for the
   function, shared by both index groups, instead of one ComputeDomain
   per distinct index.

Expected behavior

NVCA should create one ComputeDomain per distinct
required-nvlink-domain-index value present in a function's Pods, and
each Pod's channel resource claim should reference the ComputeDomain
that corresponds to its own index value.

Additional context

This is a corollary of the ComputeDomain over-allocation issue
(#1572): fixing over-allocation naturally requires deciding how many
ComputeDomain objects a function needs, and "one shared domain" was
never correct once a function can declare more than one logical NVLink
domain group.