fix: replace wildcard verbs on secrets and RBAC resources

[mgrzybek]

Finding

• Wildcard verbs on secrets cluster-wide (chart/templates/clusterrole.yaml:52–57)
• Wildcard verbs on clusterroles and clusterrolebindings — privilege escalation (chart/templates/clusterrole.yaml:85–93)

Root cause

Both rules used "*" as the verb list in the operator's ClusterRole.

The wildcard grants implicit access to any future special verb on secrets cluster-wide, including across all tenant namespaces (Keycloak admin passwords, OIDC client secrets, TLS certificates).

The wildcard on the RBAC rule implicitly included the escalate and bind verbs. escalate allows modifying any ClusterRole to add permissions beyond what the operator itself holds; bind allows creating ClusterRoleBinding objects referencing roles the operator could not normally bind to (e.g. cluster-admin). A compromised operator pod could exploit these to achieve full cluster takeover.

Changes

• chart/templates/clusterrole.yaml: replaced "*" on the secrets rule with the explicit verb set the operator actually uses (get, list, watch, create, update, patch, delete)
• chart/templates/clusterrole.yaml: replaced "*" on the RBAC rule (roles, rolebindings, clusterroles, clusterrolebindings) with the same explicit verb set, removing escalate and bind

Note 1: Full remediation (namespace-scoped Role+RoleBinding per managed namespace) requires operator code changes, because the operator writes secrets into dynamically created realm namespaces that are unknown at Helm install time. That work is tracked separately.

Note 2: clusterroles and clusterrolebindings are kept in the resource list because the Dex Helm chart creates a ClusterRole/ClusterRoleBinding for its Kubernetes storage backend. Removing escalate and bind is sufficient to block the privilege escalation path: without bind, creating a ClusterRoleBinding pointing at a more-privileged role is rejected by the Kubernetes API server's escalation-prevention check.

Merge order

No dependency on other open PRs.