v0.8.0 starts a cluster-scoped Secret informer despite namespace-scoped Secret RBAC

## Description While testing Fence Agents Remediation (FAR) v0.8.0, I observed the manager repeatedly attempting to list Kubernetes Secrets at cluster scope even though the generated FAR RBAC grants Secret access only through a namespace-scoped `Role`. This appears to be a mismatch between the intended Secret access scope and the default controller-runtime cache behavior. In the same environment, creating a `FenceAgentsRemediation` resource also times out in the mutating admission webhook. The Secret cache issue is a strong candidate for that timeout because the webhook reads Secrets through `mgr.GetClient()`, although I have not yet proven that it is the only cause of the admission timeout. ## Environment * Kubernetes server: `v1.33.5` * FAR: `v0.8.0` * FAR upstream commit: `78139f2f3c2e2611863ae3bce25ac5b375d78d97` * Operator image digest: `sha256:fab0089a9d656a21c8d0a43622ebe0d6b64a6a76e586d6cb4a06f5ce21c0b583` * Operator deployment: one replica, `Ready=1`, `Available=1` * Manager container: ready, zero restarts The deployment was based on the upstream v0.8.0 manifests. Our downstream customization does not modify FAR RBAC rules or manager client/cache configuration. ## Observed behavior The FAR manager repeatedly reports: ```text ERROR controller-runtime.cache.UnhandledError Failed to watch {"reflector":"sigs.k8s.io/controller-runtime/pkg/cache/internal/informers.go:114", "type":"*v1.Secret", "error":"failed to list *v1.Secret: secrets is forbidden: User \"system:serviceaccount:node-remediation:node-remediation-controller-manager\" cannot list resource \"secrets\" in API group \"\" at the cluster scope"} ``` During a four-hour observation window, this error occurred 325 times. The first and last observed UTC timestamps were: ```text 2026-08-20T11:46:02Z 2026-08-20T15:45:04Z ``` The manager Pod remains Ready while these errors repeat, so the readiness endpoint does not expose the unusable Secret informer. ## Admission symptom Creating a `FenceAgentsRemediation` resource fails after the configured 10-second webhook timeout: ```text Error from server (InternalError): error when creating the FAR object: Internal error occurred: failed calling webhook "mfenceagentsremediation.kb.io": failed to call webhook: Post "https://node-remediation-webhook-service.node-remediation.svc:443/ mutate-fence-agents-remediation-medik8s-io-v1alpha1-fenceagentsremediation ?timeout=10s": context deadline exceeded ``` The request is rejected during admission, so no FAR resource is persisted and no fencing operation is started. The webhook Service and EndpointSlice were healthy at collection time, with a ready and serving endpoint for the manager's webhook port. ## RBAC and cache scope mismatch The generated v0.8.0 RBAC grants Secret permissions only through a namespace-scoped `Role`: https://github.com/medik8s/fence-agents-remediation/blob/v0.8.0/config/rbac/role.yaml The relevant permissions are effectively: ```yaml kind: Role rules: - apiGroups: - "" resources: - secrets verbs: - get - list - watch ``` The corresponding `ClusterRole` does not grant Secret access. This seems consistent with an intended design where FAR only accesses fencing credentials in its deployment namespace. However, the manager does not configure a namespace restriction for the Secret cache and does not bypass the cache for Secrets: https://github.com/medik8s/fence-agents-remediation/blob/v0.8.0/cmd/main.go The FAR webhook passes the manager's cached client to both the validator and defaulter: https://github.com/medik8s/fence-agents-remediation/blob/v0.8.0/internal/webhook/v1alpha1/fenceagentsremediation_webhook.go On FAR creation, the defaulter calls `applySharedSecretDefaultNameToSpec()`, which performs a `Get()` for the legacy shared Secret: https://github.com/medik8s/fence-agents-remediation/blob/v0.8.0/internal/webhook/v1alpha1/fenceagentsremediationtemplate_webhook.go FAR v0.8.0 uses controller-runtime v0.22.5. With the