Crossplane v2 Namespaced XR Migration Prompt

You are a platform engineer migrating a Crossplane control plane from the v1 model — cluster-scoped composite resources (XRs) with namespaced claims — to the Crossplane v2 model where XRs are themselves namespaced and claims go away. Done wrong, the migration orphans managed resources or deletes live cloud infrastructure. Your job is a safe, reversible plan.

I will provide:
- Current Crossplane version and target v2 version, and the provider set in use
- The existing XRDs, Compositions, and whether teams currently create Claims or XRs directly
- The multi-tenancy model (namespace-per-team, shared, ProviderConfig scoping)
- Which XRs back stateful cloud resources (databases, buckets) that must never be recreated

Your job:

1. **Model diff** — explain precisely what changes from v1 to v2: claims removed, XRs become namespaced, the `scope` field on XRDs (`Namespaced` vs `Cluster` vs `LegacyCluster`), and how existing claim/XR pairs map to a single namespaced XR. State what stays cluster-scoped (managed resources still are).

2. **XRD updates** — for each XRD, give the edited manifest with the correct `spec.scope`, and note the API-group/version implications so existing objects are not invalidated. Flag any XRD change that would cause the API server to reject or garbage-collect existing XRs.

3. **Non-destructive cutover** — sequence the steps so managed resources are never deleted: use `compositionUpdatePolicy`, deletion-policy/management-policy checks, and (where needed) re-parenting existing MRs under the new namespaced XR via composition-resource-name matching rather than recreation.

4. **RBAC & namespacing** — rewrite the Roles/RoleBindings so teams can create namespaced XRs in their own namespace, and confirm ProviderConfig references still resolve under the new scope.

5. **Verification & rollback** — commands to prove no managed resource was replaced (`kubectl get managed`, checking `EXTERNAL-NAME` is unchanged), and a rollback path if the new XRD misbehaves.

Output as: (a) a v1→v2 concept and object-mapping table, (b) edited XRD/Composition manifests per API, (c) the ordered non-destructive cutover runbook, (d) updated RBAC and verification/rollback commands. Assume production cloud resources hang off these XRs.