[Feature Request] Eliminate ClusterRole requirement in namespace-scoped mode

Is your feature request related to a problem? Please describe.

When rbac.restrictWatchNamespaces is set, the chart still creates a ClusterRole
(<release>-<ns>-manager-cluster-role, rbac.yaml:300-321) with two grants:

• namespaces get (pinned to the release namespace)
• subjectaccessreviews create

Clusters with policies that block ClusterRole/ClusterRoleBinding creation (common in
multi-tenant setups) can't install the chart in namespace-scoped mode at all, even
though the controller only operates within its watched namespaces.

Both grants are ClusterRoles only because their resource types are cluster-scoped, not
because the controller needs cluster-wide reach. Each should be reducible to a
namespaced Role.

Describe the solution you'd like

Make namespace-scoped mode require zero manager ClusterRoles by switching both grants
to namespaced equivalents:

1. SubjectAccessReview to LocalSubjectAccessReview
   NewWorkerResourceTemplateValidator uses authorizationv1.SubjectAccessReview
   (workerresourcetemplate_webhook.go:526, 572), a cluster-scoped resource. Switching to
   LocalSubjectAccessReview (namespaced), with the object's Namespace set to
   wrt.Namespace, folds the grant into the per-namespace Role. The webhook already
   rejects non-namespaced kinds (webhook.go:511-517) and always checks within
   wrt.Namespace, so a local review is always sufficient.

2. Identity suffix source: ServiceAccount UID instead of Namespace UID
   At startup the controller reads its own namespace UID for the manager identity
   suffix (main.go:195-203), used to claim Worker Deployment ownership
   (execplan.go:199-211). Reading the controller's own ServiceAccount UID instead
   (get serviceaccounts, namespaced, pinnable via resourceNames) preserves the
   "recreated -> new identity" property, since the chart owns the SA lifecycle, and
   removes the namespaces get grant.

With both changes, the manager runs on a plain namespaced Role in namespace-scoped
mode. (The optional end-user editor/viewer ClusterRoles are already gated behind
createEndUserRoles.)

Additional context

Open question for point 2: is switching the identity suffix from namespace UID to SA UID
acceptable, or is there a reason the namespace UID specifically is required? If the
recreation-detection guarantee can be relaxed, using the namespace name (already
available via POD_NAMESPACE, no API read) is an even simpler alternative.

Happy to open a PR for point 1 on its own, since it's low-risk and independent of the
identity question.

Scope caveat on "zero ClusterRoles": these two changes remove the manager
ClusterRole, but a ClusterRole still remains for the metrics auth proxy when
metrics.disableAuth is false (the default). auth_proxy.yaml grants the sidecar
tokenreviews and subjectaccessreviews create; TokenReview is inherently
cluster-scoped with no namespaced form, so it cannot be reduced to a Role.
Operators who need zero ClusterRoles in namespace-scoped mode must also set
metrics.disableAuth: true (the chart already suggests NetworkPolicy or
same-namespace Prometheus as the alternative). Worth deciding whether the chart
should validate/warn on that combination, but that is separate from this request.

Start with rbac.yaml:300-321 and trace NewWorkerResourceTemplateValidator in workerresourcetemplate_webhook.go, including the checks in webhook.go:511-517. Then read main.go:195-203 and execplan.go:199-211 to resolve whether the identity suffix should use the ServiceAccount UID or namespace name. Done means namespace-scoped mode no longer needs the manager ClusterRole, while the metrics auth proxy caveat remains explicit.