homepage: retire the fv-ml1 docker relay, its precondition is now met

stacks/ana-ml2-proxy existed for one reason, stated in its own README: ESH
could not reach the box's Docker API cross-site because of a return-route gap,
so ana-docker relayed :2354 -> :2375 from the same subnet. The README named
its own retirement condition -- "once it has a working return route to ESH,
point Homepage back at it directly and compose down this stack".

That condition is met. FV is on the mesh, vb-gateway accepts routes, and the
NH3 UDM, ESH UDM and Anaheim FortiGate all carry 10.251.0.0/16 statics toward
their local scale nodes. Verified before removing anything: esh-docker-vm
opens a TCP connection to 10.251.50.54:2375 directly.

Homepage now points at 10.251.50.54:2375 and discovers 112 services across 20
groups, so nothing regressed. The socat container is stopped and removed from
ana-docker; the compose file and README are deleted here rather than renamed,
because renaming would preserve a moving part that no longer earns its place.

stacks/ana-ml2-proxy/README.md

@@ -1,30 +0,0 @@
-# ana-ml2-proxy
-
-A one-container `socat` TCP relay on **ana-docker** that exposes **ana-ml2**'s
-Docker API (`10.250.50.54:2375`) as `10.250.50.70:2354`, so the Homepage
-dashboard on esh-docker-vm can discover ana-ml2's containers.
-
-## Why it exists
-
-ana-ml2 is up and its docker API is reachable from within Anaheim, but **not
-cross-site from ESH** — there's a return-route gap on ana-ml2 and no SSH path to
-it from the ops seats to fix its routing. ana-docker is on the same Anaheim
-subnet (reaches `10.250.50.54:2375` directly) and **is** reachable from ESH, so
-it relays. This avoids a mesh-route change (the kind that has black-holed sites)
-and needs no access to ana-ml2 itself.
-
-Plaintext, trusted mesh-internal only — the same posture as the fleet's other
-plaintext `:2375` docker hosts in `stacks/homepage/conf/docker.yaml`.
-
-## Deploy
-
-    scripts/deploy-stack.sh ana-docker ana-ml2-proxy --compose
-    ssh infra-ops@10.250.50.70 'cd /opt/docker/compose/ana-ml2-proxy && sudo docker compose up -d'
-
-Homepage's `docker.yaml` `ana-ml2-docker` entry points at `10.250.50.70:2354`
-(the proxy), not `10.250.50.54:2375` directly.
-
-## Undo
-
-Once ana-ml2 has a working return route to ESH, point Homepage's `ana-ml2-docker`
-back at `10.250.50.54:2375` and `docker compose down` this stack.

stacks/ana-ml2-proxy/compose.yaml

@@ -1,24 +0,0 @@
----
-# TCP proxy on ana-docker: exposes ana-ml2's Docker API (10.250.50.54:2375) as
-# 10.250.50.70:2354 so Homepage on esh-docker-vm can discover ana-ml2's
-# containers.
-#
-# WHY: ana-ml2 is up and its docker API is reachable from within Anaheim, but
-# NOT cross-site from ESH (a return-route gap on ana-ml2 itself; there is no SSH
-# path to ana-ml2 from the ops seats to fix its routing). ana-docker sits on the
-# same Anaheim subnet, reaches ana-ml2:2375 directly, and IS reachable from ESH,
-# so it relays. Plaintext, trusted mesh-internal only — same posture as the
-# fleet's other plaintext :2375 docker hosts (docker.yaml).
-#
-# UNDO: once ana-ml2 has a working return route to ESH, point Homepage's
-# ana-ml2-docker entry back at 10.250.50.54:2375 directly and `docker compose
-# down` this stack.
-services:
-  ana-ml2-docker-proxy:
-    image: alpine/socat@sha256:ef6c281978dcd6927d9b3829484e4c4fdfc5d98de5acbd6312c04565d2d58cbf
-    container_name: ana-ml2-docker-proxy
-    restart: unless-stopped
-    # host networking so socat binds ana-docker's :2354 and reaches ana-ml2 over
-    # the host's Anaheim-subnet route; no bridge/port-map hop needed.
-    network_mode: host
-    command: TCP-LISTEN:2354,fork,reuseaddr TCP:10.250.50.54:2375