Document how to change provider registries

[negz]

This PR adds a guide for safely changing providers between compatible packages in different OCI registries (e.g., upbound → crossplane-contrib).

The guide focuses on the manual coordination approach needed when providers have family dependencies that create ownership conflicts. Includes step-by-step process, troubleshooting, and rollback procedures.

Also adds cross-reference from the upgrade-to-v2 guide for users switching registries during their v2 upgrade.

[netlify]

✅ Deploy Preview for crossplane ready!

Name	Link
🔨 Latest commit	ed31ce5
🔍 Latest deploy log	https://app.netlify.com/projects/crossplane/deploys/68b23e82074c6f0008414aef
😎 Deploy Preview	https://deploy-preview-984--crossplane.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 94 (🔴 down 1 from production) Accessibility: 90 (🔴 down 2 from production) Best Practices: 92 (no change from production) SEO: 100 (no change from production) PWA: 70 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[negz]

I realized there's a simpler approach:

1. Update dependencies (i.e. family provider) in place by changing their OCI ref
2. Update dependents

In simple tests this seems to work fine.

[negz]

In simple tests this seems to work fine.

I've tested it and it works, but it feels like it's dependent on a shortcoming in the package manager.

I'd expect that the dependent packages would attempt to self-heal by reinstalling their dependency once it's gone. So:

1. I edit the upbound-provider-family-gcp provider to switch it to use xpkg.crossplane.io/crossplane-contrib/provider-family-gcp
2. Crossplane notices one or more providers depend on the xpkg.upbound.io/upbound/provider-family-gcp package
3. The xpkg.upbound.io/upbound/provider-family-gcp package no longer appears in the Lock, so Crossplane re-solves and reinstalls it

Step 3 doesn't happen though, because the package manager only solves and installs dependencies at package install time. If the dependencies are removed after the package is installed, the packages just start saying they're unhealthy and missing deps.

So I'm hesitant to document this simpler approach, because it won't work if we improve the package manager's self-healing of dependencies.