fix(alloy): narrow the collector RBAC to required permissions

[jtslear]

Summary

Narrow the Alloy ClusterRole to the permissions the collector config uses:

• pods: get, list, watch (pod discovery)
• nodes: get, list, watch (node discovery)
• nodes/metrics: get (cAdvisor scrape through the kubelet)

Review of coder/dogfood#702 (v0.8.0 bump), finding CRF-8, deferred to Linear PLE-21: https://github.com/coder/dogfood/pull/702#discussion_r4267633852

The Alloy subchart default grants cluster-wide get/list/watch on secrets and configmaps, and rules for podlogs, prometheusrules, alertmanagerconfigs, podmonitors, servicemonitors, probes, scrapeconfigs, events, replicasets and /metrics. The collector config uses none of them. A token read from an Alloy pod on any node can list every Secret in the cluster. The grant also exists with grafana-agent, so this is not new, but it is now fixed for every user of the chart and not only dogfood.

Behaviour change

Users who add components through alloy.extraBlocks that need more access must override alloy.rbac.rules and alloy.rbac.clusterRules. Added to CHANGELOG.md.

Test

Kind cluster testing at baseline is main: 12 rules, including secrets and configmaps.

check	result
ClusterRole alloy rules	pods, nodes, nodes/metrics only
kubectl auth can-i --list --as=system:serviceaccount:coder-observability:alloy	nodes and pods get/list/watch, nodes/metrics get; nothing for secrets or configmaps
can-i list secrets -A, can-i list configmaps -A	no
Alloy logs	no forbidden or unauthorized lines
Pod discovery	14 up series in coder-observability, 10 pods with up == 1
cAdvisor scrape	17 container_memory_working_set_bytes series fresh within 60s

Notes

• compiled/resources.yaml and README.md regenerated with make build and make readme.
• kubectl auth can-i list nodes/pods printed yes in this cluster, which --list does not support. I treat it as a can-i quirk with subresources and did not rely on it.