feat(sms): add BlueBubbles iMessage delivery (Docker-OSX macOS VM pinned to worker-2) + ArgoCD app + dedicated longhorn-imessage-local SC — default longhorn SC can't schedule a 3-replica 200Gi volume (only worker-1 has 200Gi free at 100% over-provisioning) and Immediate binding would pin the qcow2 to the wrong node

- namespace: PodSecurity privileged, needed for /dev/kvm + privileged QEMU
- storageclass: 1 replica, strict-local, WaitForFirstConsumer
- deployment: nodeSelector workload=imessage + matching NoSchedule toleration,
  Recreate strategy (two QEMU procs on one qcow2 corrupts it), no readiness
  probe (guest install is interactive and takes many minutes)
- services: ClusterIP only; VNC is an unauthenticated console, reach it with
  port-forward, never an Ingress
- networkpolicy: default-deny, opt-in via sms-client=true on port 1234

k8s/apps/sms/storageclass.yaml

@@ -0,0 +1,32 @@
+# Dedicated StorageClass for the macOS VM disk.
+#
+# The default `longhorn` class does not work here, for two independent reasons:
+#
+# 1. Replica count. Default is 3, and Longhorn schedules against
+#    storageMaximum - storageScheduled with over-provisioning at 100%. Free
+#    space is cp-1 146Gi / cp-2 8Gi / cp-3 146Gi / worker-1 292Gi, so a 200Gi
+#    volume has only one node that can hold even a single replica — a 3-replica
+#    volume fails outright with ReplicaSchedulingFailure.
+# 2. Binding mode. `Immediate` provisions the volume the moment the PVC is
+#    created, before any pod is scheduled. Combined with strict-local that
+#    pins the data to an arbitrary node, not the one the VM runs on.
+#
+# So: one replica, kept local to the VM, bound only once the pod has a node.
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: longhorn-imessage-local
+provisioner: driver.longhorn.io
+allowVolumeExpansion: true
+reclaimPolicy: Delete
+# The pod is pinned to worker-2 by nodeSelector; wait for it to be scheduled so
+# the replica is placed on that node and not somewhere else.
+volumeBindingMode: WaitForFirstConsumer
+parameters:
+  # A qcow2 backing a live VM is latency-sensitive and rewritten constantly.
+  # Serving it over the network from another node's disk would be the single
+  # worst thing for guest responsiveness, so force it local.
+  numberOfReplicas: "1"
+  dataLocality: "strict-local"
+  staleReplicaTimeout: "30"
+  fsType: "ext4"