Support runtime.wasmcloud.dev RBAC as Namespaced vs Cluster

Summary

When the operator is configured to watch a fixed set of namespaces
(operator.watchNamespaces), it no longer needs — and should not be granted —
cluster-wide access to the runtime.wasmcloud.dev apiGroup resources. This PR
makes the operator's workload-side RBAC follow the watch scope: cluster-wide
when watching all namespaces, namespaced when watchNamespaces is set.

Concretely, when operator.watchNamespaces is non-empty, access to
artifacts, workloads, workloadreplicasets, and workloaddeployments
(plus their /status and /finalizers subresources) is granted via a Role +
RoleBinding in each watched namespace instead of a cluster-wide ClusterRole.
The shared core resources (configmaps/secrets/services/events) and
endpointslices are converted to the same per-namespace pattern.

Motivation

Previously the main operator ClusterRole always granted the
runtime.wasmcloud.dev CRD verbs cluster-wide, regardless of watchNamespaces.
For a watchNamespaces install that is broader than the operator actually uses:
the workload-side informer cache is already scoped to the watched namespaces via
cacheOpts.DefaultNamespaces (runtime-operator/cmd/main.go), so the
controllers only ever read/write these resources within those namespaces.

Granting them per-namespace:

• follows least privilege — the operator's ServiceAccount only holds permissions
  in the namespaces it manages;
• lets a namespace-scoped install be performed with namespace-admin RBAC for the
  workload resources rather than cluster-admin.

What changed

All changes are in the runtime-operator Helm chart; no operator code or
generated manifests changed.

Resulting RBAC

watchNamespaces: [] (watch all — default, unchanged behavior):

• one cluster-wide ClusterRole + ClusterRoleBinding carrying the
  runtime.wasmcloud.dev CRD rules and the cluster-wide core/discovery rules.

watchNamespaces: [team-a, team-b]:

• no operator ClusterRole/ClusterRoleBinding;
• per watched namespace: …-workload-crd, …-workload-namespace,
  …-endpointslice Role + RoleBinding;
• …-leader-election Role remains in the operator's own namespace.

Host CRDs are unaffected — they always live in the operator's own namespace and
continue to be granted by the namespaced Role in role.yaml.

Why it's safe

The workload-side informer cache is scoped to watchNamespaces via
cacheOpts.DefaultNamespaces, so the controllers never list/watch these
resources cluster-wide. Namespaced RBAC is therefore sufficient for all
list/watch/CRUD the controllers perform, including stamping owner references with
blockOwnerDeletion=true (the GC admission plugin's update on
<owner>/finalizers check is satisfied within each namespace).

No RBAC drift

This is a chart-only change that relocates where permissions are bound; it does
not add or remove any permission from the set declared by the +kubebuilder:rbac
markers. runtime-operator/config/rbac/role.yaml (generated by controller-gen)
is unchanged, so the make manifests drift guard continues to pass. The
per-namespace scoping is a Helm-only concern that controller-gen cannot
express, so it intentionally lives only in the chart.

Testing

Verified all with a local Kind cluster install:

• helm lint passes.
• helm template rendered with watchNamespaces empty and with
  watchNamespaces={team-a,team-b}, verifying:
  • watch-all: operator ClusterRole/ClusterRoleBinding present with CRD rules;
  • scoped: operator ClusterRole/ClusterRoleBinding absent; Role +
    RoleBinding present in each watched namespace with the full CRD rules
    (incl. /status and /finalizers).
• Deployed Helm chart to cluster with cluster-wide permissions
• Deployed Helm chart with Host specific namespaces

Out of scope / follow-ups

• Gateway (gateway.enabled, default true) (deprecated) grants cluster-wide
  hosts/workloads; could be converted to per-namespace Roles in a follow-up.
• Metrics (metrics-auth/metrics-reader) use tokenreviews,
  subjectaccessreviews, and nonResourceURLs — inherently cluster-scoped APIs
  that cannot be namespaced; they could only be gated behind a values flag.

Signed-off-by: Jeremy Fleitz jeremy@cosmonic.com