Fix NFS mount device strings on lxc-docker: use FQDN, not search domain

The previous commit's networking.search fix was wrong. Confirmed live
on lxc-docker (vmid 105) after redeploying with it: `resolvectl query
server.sweet.home` started failing again, even though
`resolvectl query --interface=eth0 server.sweet.home` still resolved
correctly to the right IP via the LAN's real DNS server. The debug log
showed why -- adding a *global* search domain via networking.search
gave systemd-resolved a domain-matched but server-less "global" scope,
which it now prioritizes over eth0's correctly-configured scope for
every "*.sweet.home" query, silently sending them to public fallback
DNS (1.1.1.1 et al) instead, which of course returns NXDOMAIN for an
internal-only name. Bare single-label names (e.g. "server") were never
going to work either way -- systemd-resolved only ever tries LLMNR for
those, never DNS search-suffixing, regardless of configuration.

Reverts the networking.search addition and instead has
modules/docker/mount-data.nix build each NFS device string from
"${vars.nfsServerHost}.${vars.homeDomain}" (a plain FQDN, no dependency
on search-domain behavior at all) -- the same pattern
modules/raspi/mount-data.nix already uses for the Raspberry Pi's share
and for the identical reason.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T48qgH3VTvs8wvwj44FEbE

modules/common/configuration.nix

@@ -13,24 +13,6 @@
 
   networking.networkmanager.enable = true; # Easiest to use and most distros use this by default.
 
-  # No host declares a DNS search domain anywhere else, and cross-host
-  # references throughout this repo (vars.nfsServerHost, vars.nixCacheHost,
-  # vars.dockerHost, ...) are bare short names, not FQDNs -- resolving them
-  # depends entirely on whatever network stack happens to be in play
-  # picking up the DHCP-advertised domain as a search suffix. NetworkManager
-  # does that by default, which is why this went unnoticed on
-  # NetworkManager-managed hosts, but LXC containers (modules/platforms/lxc.nix
-  # force-disables NetworkManager and Proxmox writes their systemd-networkd
-  # config itself) never get one. Confirmed live on lxc-docker: systemd-resolved
-  # had no search domain for eth0, "server" failed to resolve
-  # ("Name or service not known") while "server.sweet.home" resolved fine via
-  # the same DNS server, so every NFS mount in modules/docker/mount-data.nix
-  # failed even after fixing the automount/mount=nfs bugs. This applies the
-  # search domain globally via systemd-resolved's own config rather than the
-  # per-link DHCP path, so it isn't at the mercy of whichever component owns
-  # a given host's interface file.
-  networking.search = [ vars.homeDomain ];
-
   # Recommended over the true default (bypasses ZFS's own import safeguards)
   # per the option's own docs; matches hosts/docker/host.nix and
   # modules/services/zfs/enable-service.nix, which already set this

modules/docker/mount-data.nix

@@ -9,11 +9,25 @@ let
   # (the VM platforms rely on automount itself to get that same
   # non-blocking behavior, so they don't need `nofail` too).
   automountOpts = if config.boot.isContainer then [ "nofail" ] else [ "x-systemd.automount" ];
+
+  # A bare hostname here never resolves reliably: systemd-resolved only
+  # ever tries LLMNR for single-label names (never DNS, regardless of any
+  # configured search domain), and a *global* search domain (the first fix
+  # attempted here) backfires worse -- confirmed live on lxc-docker, adding
+  # `networking.search` made systemd-resolved prioritize its domain-matched
+  # but server-less global scope over eth0's correctly-configured one for
+  # every "*.sweet.home" query, silently sending them to public fallback
+  # DNS instead. `resolvectl query --interface=eth0 server.sweet.home`
+  # resolved fine throughout, proving the LAN DNS server was never the
+  # problem -- only the ambient, unqualified device string was. Using the
+  # FQDN directly sidesteps all of that, matching the pattern
+  # ../raspi/mount-data.nix already uses for the same reason.
+  nfsServer = "${vars.nfsServerHost}.${vars.homeDomain}";
 in
 {
   fileSystems = {
     ${vars.nfsShares.dockerConfig.mountpoint} = {
-      device = "${vars.nfsServerHost}:${vars.storageRoot}/${vars.nfsShares.dockerConfig.subpath}";
+      device = "${nfsServer}:${vars.storageRoot}/${vars.nfsShares.dockerConfig.subpath}";
       fsType = "nfs";
 
       options = [
@@ -24,7 +38,7 @@ in
     };
 
     ${vars.nfsShares.dockerDatabases.mountpoint} = {
-      device = "${vars.nfsServerHost}:${vars.storageRoot}/${vars.nfsShares.dockerDatabases.subpath}";
+      device = "${nfsServer}:${vars.storageRoot}/${vars.nfsShares.dockerDatabases.subpath}";
       fsType = "nfs";
 
       options = [
@@ -35,7 +49,7 @@ in
     };
 
     ${vars.nfsShares.dockerVolumes.mountpoint} = {
-      device = "${vars.nfsServerHost}:${vars.storageRoot}/${vars.nfsShares.dockerVolumes.subpath}";
+      device = "${nfsServer}:${vars.storageRoot}/${vars.nfsShares.dockerVolumes.subpath}";
       fsType = "nfs";
 
       options = [
@@ -46,7 +60,7 @@ in
     };
 
     ${vars.nfsShares.nextcloudData.mountpoint} = {
-      device = "${vars.nfsServerHost}:${vars.storageRoot}/${vars.nfsShares.nextcloudData.subpath}";
+      device = "${nfsServer}:${vars.storageRoot}/${vars.nfsShares.nextcloudData.subpath}";
       fsType = "nfs";
 
       options = [
@@ -57,7 +71,7 @@ in
     };
 
     ${vars.nfsShares.raspiVolumes.mountpoint} = {
-      device = "${vars.nfsServerHost}:${vars.storageRoot}/${vars.nfsShares.raspiVolumes.subpath}";
+      device = "${nfsServer}:${vars.storageRoot}/${vars.nfsShares.raspiVolumes.subpath}";
       fsType = "nfs";
 
       options = [