Mount NFS destinations with nolock so they need no nfs-common (0.66.2)

An NFSv3 mount with locking makes the kernel register its lock manager
with rpcbind on the Docker host itself. On a host without nfs-common the
mount fails with a bare "connection refused" that reads like the NAS is
unreachable, even though the NAS and its ports are fine.

Only StackPilot ever writes the backup files on an NFS destination, one
writer per file, so nothing needs locking. mount_options() now adds
nolock unless the options already choose (lock, nolock, local_lock=) or
ask for NFSv4, which locks in-protocol and needs no rpcbind. Existing
destinations get their volume recreated once with the new options.

The refused-mount hint now points at rpcbind/nfs-common on the Docker
host first, and "protocol not supported" explains the missing kernel
module (modprobe nfsv4). The form labels the option.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -636,6 +636,10 @@ it is what your saved destination credentials are encrypted with.
   NFS needs no privileges in the StackPilot container: the Docker daemon mounts
   the export as a named volume (`stackpilot-nfs-dest-<id>`, recreated when the
   config changes) and file I/O runs through throwaway helper containers.
+  StackPilot adds `nolock` to NFSv2/3 mount options unless you set `lock` or
+  `local_lock=` yourself: with locking the kernel needs rpcbind on the Docker
+  host (nfs-common), and without it the mount fails with "connection refused".
+  Only StackPilot writes the backup files, so nothing needs locking (0.66.2).
 - **Push & restore**: the stack Backup dialog can push straight to a destination
   instead of downloading; the Restore dialog can browse a destination's backups
   and restore (volumes included) directly from it. Backups can also be