fix(cluster): grant queue-operator watches and retire the macOS workload

queue-operator could not list temporalworkers.kmsvc.io or deployments.apps
at cluster scope, so its informers failed on every retry and it reconciled
nothing. Add those rules to the ClusterRole.

macos-bluebubbles pins itself to a node labelled workload=imessage, and no
such node exists. Its PVC macos-disk uses StorageClass longhorn-imessage-local
and stayed unbound for 71 days. Scale the Deployment to 0 and record why.

k8s/apps/messaging/queue-crd/templates/rbac.yaml

@@ -12,6 +12,19 @@ rules:
   - apiGroups: ["kmsvc.io"]
     resources: ["queues"]
     verbs: ["get", "list", "watch", "update", "patch"]
+  # The operator watches TemporalWorker objects and creates Deployments for
+  # them. Without these two rules the controller logs
+  # "cannot list resource temporalworkers/deployments ... at the cluster scope"
+  # and never reconciles.
+  - apiGroups: ["kmsvc.io"]
+    resources: ["temporalworkers"]
+    verbs: ["get", "list", "watch", "update", "patch"]
+  - apiGroups: ["kmsvc.io"]
+    resources: ["temporalworkers/status"]
+    verbs: ["get", "update", "patch"]
+  - apiGroups: ["apps"]
+    resources: ["deployments"]
+    verbs: ["get", "list", "watch", "create", "update", "patch"]
   - apiGroups: ["kmsvc.io"]
     resources: ["queues/status"]
     verbs: ["get", "update", "patch"]

k8s/apps/sms/deployment-macos.yaml

@@ -34,7 +34,12 @@ metadata:
     app.kubernetes.io/name: macos-bluebubbles
     app.kubernetes.io/part-of: sms
 spec:
-  replicas: 1
+  # Scaled to 0 on 2026-10-24. The pod pinned itself to a node labelled
+  # workload=imessage, and no such node exists any more. The PVC macos-disk also
+  # uses StorageClass longhorn-imessage-local, which pins the same dead node and
+  # stayed unbound for 71 days. The macOS guest therefore cannot start. Raise
+  # this to 1 again only after a KVM-capable node carries that label and taint.
+  replicas: 0
   # Recreate: the qcow2 disk is RWO and a second pod must never attach it
   # concurrently — two QEMU processes on one image corrupts it.
   strategy: