samba: restart the pod when smb.conf changes

smb.conf is rendered from samba.shares and mounted with subPath, so adding,
renaming or re-scoping a share rewrote the ConfigMap while the running smbd
kept its old share list: the pod template was unchanged, nothing restarted,
and the kubelet does not refresh subPath mounts. The share simply did not
exist for clients while the release looked healthy - the failure mode from #82.

The pod template now carries checksum/config over the rendered ConfigMap.

users.conf cannot be covered the same way: it comes from a 1Password-backed
Secret whose content Helm never sees, and the operator's auto-restart only
handles Deployments, not this StatefulSet. values.yaml now documents that
limitation and the manual rollout restart it requires.

Major bump: runtime behavior changes - a share change now costs a restart of
the samba pod, which drops open SMB sessions (share data lives on PVCs and is
unaffected).

samba/templates/samba.sfs.yaml

@@ -15,6 +15,16 @@ spec:
       name: {{ .Release.Name }}-{{ .Chart.Name }}-sfs
       labels:
         app: {{ .Release.Name }}-{{ .Chart.Name }}-sfs
+      annotations:
+        # Hash of the rendered ConfigMap: a changed smb.conf (i.e. a changed
+        # samba.shares list) changes the pod template and thus restarts the
+        # pod. Without it a new or renamed share never reaches the running
+        # smbd - smb.conf is mounted with subPath (never refreshed by the
+        # kubelet) and is read once at start.
+        # users.conf is NOT covered: it comes from a 1Password-backed Secret
+        # whose content Helm never sees. See secrets.sambaUsersSecretRef in
+        # values.yaml.
+        checksum/config: {{ include (print $.Template.BasePath "/samba-config.configmap.yaml") . | sha256sum }}
     spec:
       containers:
         - name: {{ .Release.Name }}-{{ .Chart.Name }}-sfs