feat(nh3-pve): prepare for GPU install — pin NIC names by MAC, pull AMT port from vmbr0

nh3-pve and esh-pve are the same Minisforum MS-01 (BIOS AHWSA.1.17). With a
card in the x16 slot its root port takes bus 01 and every NIC moves down a
bus (measured on esh-pve), so predictable names change (enp2s0f0np0 ->
enp3s0f0np0 etc.) and vmbr0 would boot with no uplink. systemd .link files
now pin all NICs by MAC, baked into every initramfs and synced to the ESP;
udev confirms the files apply. The AMT-capable I226-LM (enp88s0) leaves
vmbr0's bridge-ports in the file (next boot), so cabling it for AMT cannot
loop the STP-less bridge.

Also: documented the NanoKVM (https://10.100.250.171) as nh3-pve's console
OOB and that AMT is not wired; nh3-dev's Beszel agent no longer binds NAS
shares (it died on the last NH3 cold start); post-boot checklist in
persistent-memory.

stacks/beszel/README.md

@@ -22,17 +22,16 @@ filesystem samples verified; fleet 13/14 up with known fv-ml1 outage.
 | esh-docker-vm (hub name esh-vm-docker) | beszel-agent-esh | /mnt/backup, /mnt/books |
 | irv-ml1 | beszel-agent-irv | /worktank, /storetank, /mnt/smithy |
 | vm-esh-nas | beszel-agent-esh-nas | /mnt/books, /mnt/share, /mnt/music, /mnt/media |
-| nh3-dev | beszel | /mnt/backup, /mnt/smithy |
+| nh3-dev | beszel | none since 2026-09-25 (was /mnt/backup, /mnt/smithy — see below) |
 | esh-ml1 (added 2026-09-25) | beszel | none — NVIDIA image (`hosts/esh-ml1.yaml`) for the RTX 2000E Ada |
 
 ⚠ **nh3-dev's agent was DOWN from the 2026-09-24 NH3 power recovery until
 2026-09-25.** Docker could not bind `/mnt/smithy` at boot ("no such device"): since
 `1cbde50` the NAS shares are automounted, and nh3-nas was not up yet. Docker does not
 retry a container that fails to *create*, so `unless-stopped` never brought it back.
-Started by hand. **It will recur on the next NH3 cold start** until the agent stops
-depending on NAS mounts at boot. The NAS capacity is already reported by
-nh3-nas's own agent, so dropping the two extra filesystems here is the simplest fix.
-Open item.
+Started by hand, then **fixed the same day**: `hosts/nh3-dev.yaml` no longer binds
+the NAS shares and `BESZEL_EXTRA_FS` is empty. Their capacity is nh3-nas's own
+volume, which nh3-nas's agent reports.
 
 Use `infra-ops@<ip>` with passwordless sudo, except vm-esh-nas:
 `lkraven@10.0.50.154` has Docker access. Irvine's hub address is
@@ -71,7 +70,7 @@ The reusable playbook is `playbooks/beszel-filesystems.yaml` with `stack_dir`,
 `host_name`, and `extra_fs` variables. Environment backups are kept in
 `.env.before-fleet-wiring-20260910` on each host.
 
-nh3-dev has the older `docker-compose` command; use that spelling. It also
+nh3-dev now has the `docker compose` plugin (v5.5.1, 2026-09-25); the old `docker-compose` binary is gone. It also
 requires the external `traefik-net` network to exist even for the agent profile.
 Only the Beszel agent is started there. On other hosts, use `docker compose`.
 

stacks/beszel/hosts/nh3-dev.yaml

@@ -1,5 +1,11 @@
+# nh3-dev — deliberately NO extra filesystems (changed 2026-09-25).
+#
+# This override used to bind /mnt/backup and /mnt/smithy, two nh3-nas NFS
+# shares. Since 1cbde50 those are automounted on first access, and on an NH3 cold
+# start the NAS is the slowest box up. Docker then failed to bind the share
+# ("no such device"), and it never retries a container that fails to CREATE, so
+# the agent stayed dead from the 2026-09-24 power recovery until it was noticed.
+# Their capacity is nh3-nas's own volume, which nh3-nas's agent already reports,
+# so dropping them loses no information and removes the agent's dependency on the NAS.
 services:
-  beszel-agent:
-    volumes:
-      - /mnt/backup:/extra-filesystems/backup:ro
-      - /mnt/smithy:/extra-filesystems/smithy:ro
+  beszel-agent: {}