Test OLMv0 to OLMv1 upgrade path/migration

[coderabbitai]

Overview

This issue tracks the work to add end-to-end tests covering the upgrade/migration path from OLMv0 (classic OLM via Subscription/ClusterServiceVersion) to OLMv1 (via ClusterExtension API) for the OADP operator.

Background

PR #2160 adds OLMv1 lifecycle tests (install, upgrade within OLMv1, CRD validation, deprecation checks). However, there is currently no test coverage for the scenario where an operator already installed via OLMv0 is migrated or upgraded to be managed by OLMv1.

Goals

• Validate that an OADP operator instance installed via OLMv0 (Subscription + OperatorGroup) can be successfully migrated to OLMv1 (ClusterExtension).
• Ensure CRDs, existing DataProtectionApplication CRs, and Velero resources survive the migration without data loss or downtime.
• Verify that the controller-manager pod transitions cleanly under OLMv1 management post-migration.
• Cover any necessary RBAC, namespace, or installMode changes (e.g., inline.watchNamespace in OLMv1 vs. watchNamespace env var / OperatorGroup scope in OLMv0).

References

• PR feat: OLMv1 lifecycle — fresh install tests + OLMv0→OLMv1 migration target #2160: feat: OLMv1 lifecycle — fresh install tests + OLMv0→OLMv1 migration target #2160
• OLMv0 install mode in CSV:

  oadp-operator/config/manifests/bases/oadp-operator.clusterserviceversion.yaml

  Lines 467 to 475 in 7e53a85

  	installModes:
  	- supported: true
  	type: OwnNamespace
  	- supported: false
  	type: SingleNamespace
  	- supported: false
  	type: MultiNamespace
  	- supported: false
  	type: AllNamespaces

• OLMv0 watchNamespace config:

  oadp-operator/config/manager/manager.yaml

  Lines 63 to 66 in 7e53a85

  	- name: WATCH_NAMESPACE
  	valueFrom:
  	fieldRef:
  	fieldPath: metadata.namespace

Requested by @kaovilai.