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/pvc-macos.yaml

@@ -0,0 +1,25 @@
+# Persistent macOS disk image + generated hardware identity (bootdisk.qcow2).
+#
+# This volume is NOT disposable: it holds the VM's serial number, board serial,
+# UUID and MAC, which together form the identity iMessage was activated against.
+# Losing it means re-running activation, which is the least reliable step of the
+# whole setup.
+#
+# Docker-OSX documents 128GB minimum for the guest image; 200Gi leaves room for
+# the installer, the base system, and qcow2 growth.
+#
+# ⚠️ Single replica (see storageclass.yaml — capacity and IO both rule out 3).
+# Losing worker-2's disk therefore means losing the activated identity and
+# redoing iMessage activation. Once the guest is installed and activated, take
+# a Longhorn snapshot/backup of this volume; that is the only redundancy here.
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: macos-disk
+spec:
+  accessModes:
+    - ReadWriteOnce
+  storageClassName: longhorn-imessage-local
+  resources:
+    requests:
+      storage: 200Gi