zood-mv: follow the disk, not the architecture

Its 40Gi chain volume is a local-path PV on spark, so spark is the only node
that can mount it. The amd64 pin named evo and the pod went Pending on a
PersistentVolume node-affinity mismatch. The image being amd64-only argues for
evo, but spark runs it under its registered qemu-x86_64 binfmt handler, the same
way the object store does there. Placement follows the disk; the disk does not
move.

Co-authored-by: Hanzo Dev <[email protected]>

deploy/zoo-mainnet/zood-mv.yaml

@@ -149,12 +149,11 @@ pdb:
   enabled: true
   maxUnavailable: 1
 
-# The image for this workload is published for linux/amd64 only, and this
-# cluster has an arm64 node. Unpinned, the scheduler is free to place it on
-# spark, where the kubelet refuses the pull with `no match for platform in
-# manifest` -- which reads as a broken image and is a misplaced pod. Measured
-# 2026-09-09: zoo-ui, zoo-gym, zoo-bot and zoo-build had all been sitting in
-# ImagePullBackOff on spark. Pin follows the artifact: an image that exists for
-# one architecture may only be scheduled where that architecture is.
+# By HOSTNAME, not architecture: this node's 40Gi chain volume
+# (data-zood-mv-0) is a local-path PV that exists only on spark's disk, and a
+# pod placed anywhere else cannot mount it. The image is published amd64-only,
+# which reads as an argument for pinning to evo -- but spark runs it through its
+# registered qemu-x86_64 binfmt handler, the same way the object store does.
+# Placement follows the disk; the disk does not move.
 nodeSelector:
-  kubernetes.io/arch: amd64
+  kubernetes.io/hostname: spark