Description of problem:

Creating this (inside a Policy):

apiVersion: policy.open-cluster-management.io/v1beta1
kind: OperatorPolicy
metadata:
  name: loki-operator-policy
spec:
  complianceType: musthave
  remediationAction: enforce
  severity: medium
  subscription:
    name: loki-operator
    namespace: openshift-operators-redhat
    source: redhat-operators
    sourceNamespace: openshift-marketplace
  upgradeApproval: Automatic 

results in a NonCompliant policy with a message including "the subscription defaults could not be determined because the catalog specified in the policy does not match what was found in the PackageManifest on the cluster". Sometimes this is the only status message, and sometimes it looks like the policy begins to properly install the operator (it creates a subscription) but then it still falls into this NonCompliant state. I think sometimes it could get lucky and actually install the operator and become Compliant.

Version-Release number of selected component (if applicable): 

2.12

How reproducible:

It might be inconsistent, but it seems to happen often enough with this specific operator to be reproducible.

Steps to Reproduce:

1. Create the policy above
2. Check the status
3. If it doesn't have the error, delete all those resources and try again. Or maybe just update the `severity` or something to trigger a re-reconcile, that also might trigger the issue.

Actual results:

The policy has inconsistent "defaulting" behavior, which seems to lead to it thinking the policy is invalid. Sometimes it finds the package from the catalog specified in the policy, but sometimes it finds one from a different catalog and reports the policy as invalid. Since this happens inconsistently, the policy may begin taking some actions, and then later stop.

Expected results:

The policy should just use the package from the catalog specified in the policy. It should only report the policy as invalid if that catalog does not specify this package.

Additional info:

One workaround is to set the channel in the policy, since that avoids the package lookup which seems to be causing the issue.