Guidance for ClusterProfile consumers on namespace scope and duplicate clusters

## Summary

`ClusterProfile` consumers need clearer guidance on two points:

1. Which namespace(s) should a consumer watch?
2. What should a consumer do if the same logical cluster appears as multiple `ClusterProfile` objects across watched namespaces?

This matters because producers such as OCM can project the same managed cluster into multiple namespaces. If a consumer watches more than one of those namespaces and treats `metadata.name` as globally unique, different projections of the same cluster can collide.

There are broadly two kinds of consumers, and they have very different exposure to this problem:

* **Single named-reference consumers** resolve one specific `ClusterProfile` by namespace/name (for example, the [[Knative Operator](https://github.com/knative/operator/blob/main/docs/multicluster.md)](https://github.com/knative/operator/blob/main/docs/multicluster.md), which references a single `ClusterProfile` explicitly). These work correctly regardless of which namespace the object lives in, because identity is fully specified by the operator/user.
* **Namespace-watching consumers** select and process *all* `ClusterProfile` objects in one or more watched namespaces (for example, the Argo CD ClusterProfile controller). These are the ones exposed to cross-namespace duplication, and we expect more controllers of this type to appear over time.

Guidance is most needed for the second category.

## Concrete example

The Argo CD ClusterProfile controller currently turns each `ClusterProfile` into one Argo CD cluster `Secret`.

The Secret name is based only on:

```text
cluster-
```

With OCM, the same managed cluster can appear as multiple `ClusterProfile` objects, for example:

```text
argocd/managed1
open-cluster-management-cluster-proxy/managed1
open-cluster-management-managed-serviceaccount/managed1
```

If the controller watches multiple namespaces, all three objects map to the same Secret:

```text
argocd/cluster-managed1
```

As a result, reconciles can overwrite each other. The last reconciled `ClusterProfile` wins, and the Secret may end up containing data from a different projection than expected.

## Current behavior observed

In the Argo CD controller example:

* The controller reconciles `ClusterProfile` by namespace/name.
* The generated Secret name uses only `ClusterProfile.metadata.name`.
* The Secret is written into the controller namespace.
* There is no cross-namespace deduplication.
* There is no configured namespace priority.
* If multiple watched namespaces contain the same logical cluster, the final Secret depends on reconcile order.

This makes the behavior non-deterministic from the consumer/operator point of view.

Note that this is specific to namespace-watching consumers. A single named-reference consumer like the Knative Operator does not hit this, because the operator picks exactly one `ClusterProfile` and there is no implicit selection across namespaces.

## Questions

### 1. Should consumers generally watch a single namespace?

For OCM, the clean model seems to be:

* create a dedicated namespace for each consumer;
* bind the desired `ManagedClusterSetBinding` into that namespace;
* let the consumer watch only that namespace.

This gives the consumer one `ClusterProfile` per managed cluster and avoids cross-namespace duplicates.

Is this the expected/golden-path model for namespace-watching `ClusterProfile` consumers?

### 2. If consumers support multiple namespaces, who owns deduplication?

Should the API guidance say that:

* the same logical cluster must not appear in more than one watched namespace; and
* operators/producers are responsible for avoiding that situation?

Or should consumers be expected to deduplicate across namespaces themselves?

### 3. What should a consumer do if duplicates are detected?

Possible policies include:

* fail closed and report a clear error;
* prefer an explicitly configured namespace;
* prefer the consumer's own namespace;
* emit distinct outputs per projection by including the source id in the generated name;
* attempt to merge duplicate `ClusterProfile` objects.

## Proposed guidance

It would be helpful for SIG-Multicluster to document consumer-facing guidance for namespace scoping and duplicate handling, distinguishing the two consumer patterns:

* **Single named-reference consumers** (e.g. Knative Operator) can operate on a `ClusterProfile` in any namespace, since identity is explicitly specified. No special duplicate handling is required.
* **Namespace-watching consumers** (e.g. Argo CD ClusterProfile controller) select all `ClusterProfile` objects in the watched namespace(s) and need explicit rules for scoping and duplicates. We expect more controllers of this type, so guidance here is valuable.

A possible baseline for namespace-watching consumers:

* Producers should keep one logical cluster in one namespace.
* Consumers may support single-namespace, multi-namespace, or all-namespace watching, but the watched set must not contain duplicate logical clusters.
* If duplicates are detected, consumers should either fail closed or use an explicitly configured namespace priority.
* Consumers should not infer cluster identity from server URL equality alone.

The [Argo CD ClusterProfile controller](https://github.com/argoproj-labs/clusterprofile-integration-for-argocd) is a concrete example where this guidance would help avoid ambiguous and order-dependent behavior, and the [Knative Operator](https://github.com/knative/operator/blob/main/docs/multicluster.md) is a concrete example of the single named-reference pattern that does not need it.

Start by reviewing the proposed guidance and the linked Knative Operator multicluster.md documentation, then compare it with the Argo CD ClusterProfile controller behavior described in the issue. Resolve the namespace-scoping and duplicate-handling questions with project guidance, and document the agreed rules for named-reference and namespace-watching consumers.

Written by the indexing model from the issue text.