Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@bindings/go/transfer/integration/integration_test.go`:
- Around line 746-754: The test currently only adds a local blob via
addComponentWithResources which doesn't exercise CopyModeAllResources; update
the fixture to include a non-local resource (e.g., an OCI or Helm artifact)
instead of (or in addition to) the local blob so the CopyModeAllResources path
is hit—modify the call that creates the source component
(addComponentWithResources) to register an OCI/Helm style resource descriptor
(unique type and reference) or use an existing helper to add an OCI/Helm
resource to the ctfRepo, then invoke the transfer with CopyModeAllResources and
assert the non-local resource was copied (or that behavior differs from
CopyModeLocalBlobResources) to validate the branch (referencing
addComponentWithResources, createCTFRepository, and the CopyModeAllResources
setting).

In `@bindings/go/transfer/internal/discovery.go`:
- Around line 56-59: The code races on concurrent access to resolverMap:
Discover mutates the shared map while Resolve and other readers access it; add a
sync.RWMutex field (e.g., resolverMapMu) to the same struct that holds
resolverMap and use Lock/Unlock around writes (where Discover inserts child
resolvers and at the other write sites around the code referenced at lines
~195-200) and RLock/RUnlock around reads (e.g., in Resolve when doing
repoResolver, ok := r.resolverMap[key]) to avoid concurrent map read/write
panics; ensure the mutex is initialized as part of the struct (zero value is
fine) and apply the same locking discipline for any other accesses to
resolverMap.

In `@bindings/go/transfer/transfer.go`:
- Around line 47-49: The error message for the empty transfer mappings check
(when len(o.Mappings) == 0 in transfer.go) incorrectly repeats "WithTransfer";
update the fmt.Errorf call to a correct, non-duplicated instruction such as
fmt.Errorf("no transfer mappings specified: use WithTransfer") (or list the
actual intended option names if there are multiple), so the message accurately
guides the user.
- Around line 77-86: The loop currently sets rd.resolver only on first encounter
and silently ignores later m.Resolver values; change the logic so that when
byKey[key] already exists you compare existing rd.resolver with m.Resolver and
handle conflicts instead of silently dropping them: if rd.resolver is nil, set
it to m.Resolver; if rd.resolver is non-nil and not equal to m.Resolver, return
an error (or log a warning and return an error per reviewer guidance) indicating
a conflicting resolver for that component key; continue to always append targets
via internal.AppendUniqueRepositories(rd.targets, []runtime.Typed{m.Target}) and
preserve keyOrder behavior. Ensure you reference the same symbols (byKey,
rd.resolver, m.Resolver, rd.targets, keyOrder) when implementing the check and
error path.

---

Nitpick comments:
In `@bindings/go/transfer/transfer_test.go`:
- Around line 54-65: The fallback path in
mockCVRepoResolver.GetComponentVersionRepositoryForSpecification uses a map
iteration over m.repos which is non-deterministic; make it deterministic by
selecting a stable key (e.g., collect the keys from m.repos, sort them, and
return the repo for the first sorted key) or by explicitly looking up a known
default key, then return that repo instead of iterating the map arbitrarily.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@bindings/go/transfer/transfer.go`:
- Around line 84-86: Update the error handling and docs to explicitly document
the resolver reuse pattern: when the pointer check rd.resolver != m.Resolver
fails, enhance the error message (and/or add an inline comment near the
rd.resolver comparison and the repoResolver definition) to state that resolver
identity is checked by pointer equality and that callers must either reuse the
same resolver instance via FromResolver() or call FromRepository() only once per
component; reference the rd.resolver vs m.Resolver check and the
repoResolver/FromRepository()/FromResolver() symbols so readers know where the
requirement originates.

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@bindings/go/transfer/internal/graph.go`:
- Around line 71-95: The current discoverer/multiResolver uses shared maps
(resolverMap and discoveredDigests) with winner-takes-slot semantics, which can
hide conflicts when different recursive roots assign different resolvers or
pinned digests for the same child; update the discovery logic in discoverer
(where discoveredDigests is populated) and in the multiResolver.expectedDigest
resolution to detect conflicting assignments: when attempting to set an entry in
discoveredDigests or resolverMap for an existing key, compare the existing value
to the new one and return a descriptive error if they differ (do not overwrite),
and propagate that error up to abort the transfer; use the unique symbols
discoverer, discoveredDigests, resolverMap, and multiResolver.expectedDigest to
locate the places to add these checks and error returns.

---

Nitpick comments:
In `@bindings/go/transfer/transfer_test.go`:
- Around line 484-578: Add a regression test that verifies collectTransferRoots
rejects two mappings for the same component key when the Resolver instances
differ: create two distinct mockCVRepoResolver instances (not the same pointer),
build an Options with two Mapping entries that share the same ComponentID (e.g.,
"ocm.software/test:1.0.0") but assign different Resolver objects and the same or
different Targets, call collectTransferRoots(t.Context(), o) and assert it
returns a non-nil error (and does not silently merge); reference
collectTransferRoots, Options, Mapping, ComponentID and mockCVRepoResolver to
locate where to add the test.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@bindings/go/transfer/internal/graph.go`:
- Around line 22-29: The TransferRoot struct currently groups many Targets with
a single SourceResolver which causes the last resolver to overwrite earlier
mappings; change the shape so each target is paired with its resolver (e.g.,
replace Targets []runtime.Typed with Targets []TargetMapping where TargetMapping
has Target runtime.Typed and Resolver
resolvers.ComponentVersionRepositoryResolver) and update all
construction/consumption sites (notably the code paths in transfer.go around
WithTransfer and the other usages referenced) to emit one TransferRoot per
target-mapping or iterate TargetMapping so each target uses its own resolver;
also adjust the struct fields at the other occurrence noted (lines ~67-68) to
match the new pair shape.

---

Nitpick comments:
In `@bindings/go/transfer/internal/graph.go`:
- Around line 65-66: The code iterates Go maps (e.g., the loop building dagRoots
from roots and the loop over tgd.Transformations) which yields non-deterministic
order; sort the keys before iterating to produce stable output: collect map keys
into a slice, call sort.Strings (or appropriate comparator) and then
append/iterate in that sorted order (apply this to the roots->dagRoots
construction and the loop over tgd.Transformations/discovered component keys),
and add import "sort".