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/values.yaml

@@ -5,6 +5,19 @@
 scaleDown: false
 
 secrets:
+  # users.conf is mounted into the samba container from the Secret the 1Password
+  # operator materializes from this item.
+  #
+  # Known limitation (#82): changing the item in the vault does NOT restart
+  # samba, so added, removed or re-passworded users stay invisible to the
+  # running smbd. Helm cannot hash the content (it never sees it - the operator
+  # fills the Secret in-cluster after rendering), so the checksum/config
+  # mechanism used for smb.conf does not apply here. The operator's own
+  # "operator.1password.io/auto-restart" annotation is no help either: it only
+  # ever restarts Deployments, and this workload is a StatefulSet (verified
+  # against onepassword-operator 1.12.0). After changing the users item,
+  # restart samba by hand:
+  #   kubectl rollout restart statefulset <release>-samba-sfs
   sambaUsersSecretRef: null
 
 samba: