Retire the TrueNAS VM once the cluster runs on metal

Part of #241 (phase 3).

## Summary

Move node 1 off the TrueNAS VM onto dedicated hardware and retire the
VM, so the cluster no longer runs on the appliance it stores data on.

## Motivation

This is what the phased plan is for. ADR 0001's end state is "three
dedicated nodes beside TrueNAS; the VMs retired", with quorum and
blast radius fully decoupled from the storage appliance. Until this
lands, TrueNAS is both the storage backend and the substrate: a NAS
reboot takes the cluster with it, etcd commits compete with Plex for
`fsync` on a raidz2 pool with no separate log device, and the 2-core
Atom C3338 caps throughput.

#250 grows the cluster to three nodes on metal but assumes node 1
persists. Nothing else covers removing the VM, so the plan's whole
point had no issue behind it.

## Scope

- Drain node 1 and remove it from the cluster, letting the metal nodes
take its workloads.
- Move the GPU-affinity label and the Plex pinning to the node that
carries the QuickSync-capable iGP (#246).
- Delete the VM on TrueNAS and release the resources it held.
- Restore the ZFS cache to its pre-VM sizing (#489 records the cap
that was set).
- Confirm the reserved LAN IPs for node 1 and the VIP still resolve to
the intended hosts after the move.

## Acceptance criteria

- [ ] Node 1 drained and removed; no cluster member runs on TrueNAS
- [ ] Plex still hardware-transcodes after the GPU label moves
- [ ] VM deleted and the ZFS cache cap lifted
- [ ] A TrueNAS reboot no longer takes the cluster down
- [ ] `etcd_disk_wal_fsync_duration_seconds` measured on metal and
compared against the phase 1 baseline

## Additional context

The phase 1 risks ADR 0001 records — the 2-core ceiling, memory
contention with the ZFS cache, and etcd's `fsync` behaviour on the NAS
pool — all retire when this closes. That's the test for whether the
work is done.