Auto-claim's Service informer runs cluster-wide even when no class enables auto-claim #9

Found in the architectural review of community#35 (cozystack/community#35 (review)), against #7.

What happens

The ServiceReconciler added in #7 is built with For(&corev1.Service{}) and no predicate, so the manager's cache holds every Service in the cluster and every Service event enters the work queue, whether or not any IPAddressClass carries the auto-claim annotation. The reconciler returns early for Services that do not qualify, but the informer, the cache memory and the event traffic are paid in every installation.

When it matters

A cluster with tens of thousands of Services and no auto-claim class pays the full cost of a Service informer for nothing. The core had no Service watch before #7.

Suggested fix

One of:

• a predicate that drops Services with status.loadBalancer.ingress set, a claim annotation, or a type other than LoadBalancer, so only candidates reach the queue (the cache still holds all Services);
• a cache selector limiting the Service informer to type: LoadBalancer (a field selector on spec.type is not served by the apiserver, so this means a label contract or a transform);
• start the Service reconciler only once an auto-claim class exists, and stop it when none does.

The first is cheap and removes the queue traffic; the third removes the cache cost as well.