LeaderAwareFuncs in genreconciler do not respect classValue

On leader promotion, the controller will enqueue all known instances of `Kind` without filtering on the provided `classValue`.

```go
LeaderAwareFuncs: reconciler.LeaderAwareFuncs{
PromoteFunc: func(bkt reconciler.Bucket, enq func(reconciler.Bucket, types.NamespacedName)) error {
all, err := lister.List(labels.Everything())
if err != nil {
return err
}
for _, elt := range all {
if promoteFilterFunc != nil {
if ok := promoteFilterFunc(elt); !ok {
continue
}
}
enq(bkt, types.NamespacedName{
Namespace: elt.GetNamespace(),
Name: elt.GetName(),
})
}
return nil
},
},
```

It is only in `Reconcile(key)` that the `Kind` is filtered and prevented from calling down into `ReconcileKind`

```go
if classValue, found := original.GetAnnotations()[ClassAnnotationKey]; !found || classValue != r.classValue {
logger.Debugw("Skip reconciling resource, class annotation value does not match reconciler instance value.",
zap.String("classKey", ClassAnnotationKey),
zap.String("issue", classValue+"!="+r.classValue))
return nil
}
```

The side effect here is every `Kind` is enqueued and then noop'ed from the queue. Not a huge issue, but for a cluster with many instances of several `kinds`, it will be extra work each reconciler does not need to do.

### Possible Solution

Perhaps we generate a default filter function that can be overloaded if one is provided when we generate a reconciler with a `classValue`?

Start at the genreconciler LeaderAwareFuncs PromoteFunc and follow its interaction with Reconcile(key), including the class annotation check shown in the issue. Trace the existing promotion and reconciliation tests, if present, and verify that promotion avoids enqueueing resources with a nonmatching classValue while preserving any provided promoteFilterFunc behavior.

Written by the indexing model from the issue text.