chore(augaman): remove the fv-ml1 instance (Prime)

Prime removed the second instance after the v0.1.3 bench. esh-ml1 handles a face
in ~48 ms, sits in the house next to the cameras, and holds the verified
backup. fv-ml1's gallery was empty (0 identities). The container, gallery volume,
image, compose dir (with its .env), backup dir and build sources are removed from
fv-ml1. GPU_ID / CARD_SUFFIX stay in the compose for any future second host.

persistent-memory.md

@@ -155,12 +155,12 @@ _As of 2026-09-26 ~1620 PT._
   survived the recreate and was then deleted, so the gallery is empty and ready for real
   enrollments. `/recognize` p50 186 ms (1080p, one face). The detector-latency follow-up
   is theirs. Their next release pins the container gid to 10001; nothing is owed by infra-ops.
-- **Second instance on fv-ml1 GPU 1 (Prime, 2026-09-27)**, `GPU_ID=1`, **fixtures-only, no
-  gallery backup**, separate gallery. Its role (bench-only vs future primary) is Prime's call.
+- **The fv-ml1 instance was REMOVED by Prime on 2026-09-27 (0125 PT)** after the bench. esh-ml1 is the only
+  instance: in the house, backed up, 48 ms per face on v0.1.3.
 - **v0.1.3 live on BOTH hosts (2026-09-27 ~0105 PT).** Speed bench (`docs/pfi/augaman-speed-bench/`),
   server-side one face, v0.1.2 → v0.1.3: esh GPU 144 → 48 ms, fv GPU 75 → 27 ms. CPU mode
   REGRESSED (fv CPU6 152 → 205 ms; suspected ORT thread-pool spinning) and is reported to
-  augaman-dev; neither deployment uses CPU mode. The fv-ml1 instance's role is still Prime's call.
+  augaman-dev; the deployment does not use CPU mode.
 
 ### esh-ml1