v2: multi-consumer isolation on a shared provider

[cnvergence]

Feature Description

v1 supported multiple consumers sharing one provider namespace-space via the isolation strategies (Prefixed, Namespaced) and APIServiceNamespace mapping. The v2 slim core drops this by design: sync is scope/namespace/name-preserving, and in-core multi-consumer isolation is an explicit non-goal of v2-slim-core.md (tenancy becomes a deployment concern or an extension).

Today the answers for a shared provider are:

1. Per-consumer credentials via iam.kbind.io Grants — isolation is exactly as strong as the issued RBAC; ownership markers (core.kbind.io/managed) detect conflicts but do not protect against overprivileged credentials.
2. Unique namespaces per consumer (e.g. tenant-<id>), since sync is namespace-preserving.
3. Dedicated cluster/vcluster/kcp workspace per consumer.
4. A compile-time Mapper implementation in an out-of-tree konnector build (v1 Prefixed is implementable; scope conversion intentionally is not).

None of these gives an out-of-the-box story for "many consumers, one provider, identical namespace names". This issue tracks deciding and documenting how far v2 should go.

Proposed Solution

• Document the supported tenancy patterns (Grant boundary namespace + unique namespaces; dedicated workspace) as the recommended defaults
• Provide a reference Mapper implementation (v1-style Prefixed key mapping) as an example out-of-tree konnector build, proving the extension seam works
• Evaluate whether the issuer/backend should automate per-consumer namespace + RBAC provisioning on the provider (boundary namespace per Grant)
• Decide whether a Transformer extension point (payload mutation: label injection, field stripping) is needed for tenancy labeling — currently deferred in the proposal

Alternative Solutions

Reintroduce isolation strategies into the core API. Rejected by the v2 proposal: the core CRDs should never promise renaming, and scope conversion stays out.

Additional Context

• Proposal: docs/proposals/v2-slim-core.md (Non-Goals, "Extension point 1: Mapper")
• Docs: docs/content/usage/synchronization.md ("Cluster Isolation")
• Related: epic: Multi-Provider/Consumer Support #321 (multi-provider/consumer epic), Binding multiple provider with same CRD into one consumer cluster #173 (multiple providers, same CRD)