Using a ClusterCatalog object's status for the catalogd controller's reconcile logic is an anti-pattern we should avoid.

We currently read from ClusterCatalog status to determine whether a catalog is ready to be polled again

examples:

1. Reading from Status for comparing ObservedGeneration of conditions with current generation
   

   catalogd/internal/controllers/core/clustercatalog_controller.go

   Lines 242 to 246 in 29d21c7

   	for _, c := range catalog.Status.Conditions {
   	if c.ObservedGeneration != catalog.Generation {
   	return true
   	}
   	}

2. Using LastSuccessfulPollAttempt from status to calculate when to poll next
   

   catalogd/internal/controllers/core/clustercatalog_controller.go

   Line 252 in 29d21c7

   nextPoll := catalog.Status.ResolvedSource.Image.LastSuccessfulPollAttempt.Add(catalog.Spec.Source.Image.PollInterval.Duration)

The status field should ideally be treated as a write-only field by the controller - we should update the controller so it can track information about a ClusterCatalog's current state without having to reference the ClusterCatalog's status field, as reading from Status may read to non-deterministic behavior if reconciler runs in quick succession.

Follow up based on #384 (comment)

See https://book.kubebuilder.io/reference/good-practices, https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status