fv-ml1: the playbook + homepage body edits the rename commit missed

A zsh glob failure in the staging step of 91bda3c meant the five renamed
playbooks went in as pure renames with their bodies still saying ana-ml2 and
10.250.50.54, and the homepage docker.yaml direct-connection edit from 17586ab
did not stage either. Same content, just the half that got dropped.

playbooks/fv-ml1-mesh-routes.yaml

@@ -1,10 +1,10 @@
-# ana-ml2: persist the mesh return routes (via ana-scale 10.250.50.45) as an ifupdown if-up.d
+# fv-ml1: persist the mesh return routes (via ana-scale 10.250.50.45) as an ifupdown if-up.d
 # hook on the VLAN-50 interface. Rerunnable; `ip route replace` is idempotent.
-#   scripts/elway infra-ops@10.250.50.54 --playbook playbooks/ana-ml2-mesh-routes.yaml
+#   scripts/elway infra-ops@10.251.50.54 --playbook playbooks/fv-ml1-mesh-routes.yaml
 steps:
   - name: Install the if-up.d hook
     upload:
-      src: playbooks/files/ana-ml2-mesh-routes.sh
+      src: playbooks/files/fv-ml1-mesh-routes.sh
       dest: /etc/network/if-up.d/mesh-routes
       mode: "0755"
     sudo: true

playbooks/fv-ml1-overcommit-memory.yaml

@@ -1,6 +1,6 @@
-# Make vm.overcommit_memory=1 durable on ana-ml2 (GPU inference host).
+# Make vm.overcommit_memory=1 durable on fv-ml1 (GPU inference host).
 #
-# Why: ana-ml2 runs vm.overcommit_memory=0 (heuristic) with zero swap, so the
+# Why: fv-ml1 runs vm.overcommit_memory=0 (heuristic) with zero swap, so the
 # CommitLimit is ~RAM/2 (~283 GB of 566 GB). The resident vLLM services already
 # commit ~224 GB of address space, leaving < 60 GB of headroom. A large model-file
 # mmap (e.g. the 50 GB NVFP4 shard during HF->native conversion, or a vLLM model
@@ -12,7 +12,7 @@
 # accounting is the only thing in the way. Operator-directed permanent + durable
 # (2026-06-17). A drop-in under /etc/sysctl.d/ applies at every boot.
 #
-# Run:  scripts/elway infra-ops@ana-ml2 --playbook playbooks/ana-ml2-overcommit-memory.yaml
+# Run:  scripts/elway infra-ops@fv-ml1 --playbook playbooks/fv-ml1-overcommit-memory.yaml
 # Rerunnable: a second run shows the write step `skipped` (idempotent via when:).
 
 vars:

playbooks/fv-ml1-pool-health.yaml

@@ -1,4 +1,4 @@
-# ana-ml2 pool-health actions (operator-approved 2026-09-09, "all 3 on clean context").
+# fv-ml1 pool-health actions (operator-approved 2026-09-09, "all 3 on clean context").
 #
 #   1. kick a scrub of `tank` (2 CKSUM on nvme7n1 after the 09-05 boot resilver,
 #      no scrub since 04-12) — polled separately; `zpool clear` only after a

playbooks/fv-ml1-training-window-close.yaml

@@ -1,8 +1,8 @@
-# ana-ml2 — CLOSE the ERP/RP tune window: put the fleet back the way it was.
+# fv-ml1 — CLOSE the ERP/RP tune window: put the fleet back the way it was.
 #
 #   gen GPU1 -> GPU0  ->  start mog-sec back onto GPU1
 #
-# The exact inverse of playbooks/ana-ml2-training-window-open.yaml.
+# The exact inverse of playbooks/fv-ml1-training-window-open.yaml.
 #
 # ⚠⚠ ORDER IS LOAD-BEARING, AND IT IS THE MIRROR OF THE OPEN ORDER.
 # `gen` must vacate GPU1 BEFORE mog-sec is started. mog-sec runs at
@@ -16,10 +16,10 @@
 # OOM the run or OOM gen. Override only when you have confirmed the run is
 # finished or deliberately abandoned:
 #
-#   scripts/elway ana-ml2 --playbook playbooks/ana-ml2-training-window-close.yaml \
+#   scripts/elway fv-ml1 --playbook playbooks/fv-ml1-training-window-close.yaml \
 #     --var allow_busy_gpu0=true
 #
-#   scripts/elway ana-ml2 --playbook playbooks/ana-ml2-training-window-close.yaml
+#   scripts/elway fv-ml1 --playbook playbooks/fv-ml1-training-window-close.yaml
 
 vars:
   gen_dir: /opt/docker/compose/gen-seat

playbooks/fv-ml1-training-window-open.yaml

@@ -1,4 +1,4 @@
-# ana-ml2 — OPEN the ERP/RP tune window: clear GPU0 completely.
+# fv-ml1 — OPEN the ERP/RP tune window: clear GPU0 completely.
 #
 #   stop mog-sec (GPU1)  ->  move gen GPU0 -> GPU1  ->  GPU0 empty for training
 #
@@ -24,9 +24,9 @@
 # (MOG_GPU_ID=1) under index 1. They agree here. (They do NOT on irv-ml1 —
 # never carry that assumption between boxes.)
 #
-# Restore with: playbooks/ana-ml2-training-window-close.yaml
+# Restore with: playbooks/fv-ml1-training-window-close.yaml
 #
-#   scripts/elway ana-ml2 --playbook playbooks/ana-ml2-training-window-open.yaml
+#   scripts/elway fv-ml1 --playbook playbooks/fv-ml1-training-window-open.yaml
 
 vars:
   gen_dir: /opt/docker/compose/gen-seat

stacks/homepage/conf/docker.yaml

@@ -17,15 +17,12 @@ nh3-pfi-docker:
   host: 10.100.50.40
   port: 2375
 
-# fv-ml1-docker — reached via a socat proxy on ana-docker (stacks/fv-ml1-proxy).
-# fv-ml1's own :2375 is up but not reachable cross-site from ESH (a return-route
-# gap on fv-ml1 itself; no SSH access from the ops seats to fix its routing).
-# ana-docker is on the same Anaheim subnet and IS reachable from ESH, so it
-# relays 10.250.50.70:2354 -> 10.251.50.54:2375. Point back at 10.251.50.54:2375
-# and `docker compose down` the proxy once fv-ml1 has a return route to ESH.
+# fv-ml1-docker — direct. The socat relay on ana-docker (stacks/fv-ml1-proxy) was
+# retired 2026-09-12: once FV joined the mesh and the three site gateways got
+# 10.251.0.0/16 statics, ESH reaches fv-ml1:2375 directly (verified).
 fv-ml1-docker:
-  host: 10.250.50.70
-  port: 2354
+  host: 10.251.50.54
+  port: 2375
 
 # irv-ml1 — moved 10.100.79.3 -> 10.6.110.50 on 2026-09-06 (headscale cutover;
 # the old wg0 tunnel IP is dormant and no longer answers). Reachable from