zood-mv: the digest names v1.36.58 while the tag says v1.36.68

26e7154 moved the tag from v1.36.58 to v1.36.68 to stop this file declaring a
version behind the fleet, and left the digest on v1.36.58's bytes. A reference
carrying both resolves BY DIGEST, so the declaration it left behind was the one
it set out to remove -- run .58, report .68 -- and now with the tag agreeing
with the running fleet, nothing was left to notice it. That is the failure mode
worth naming: a drifted pin does not fail, it succeeds at doing nothing.

Both halves are now v1.36.68 (ebd16ed5…), read from the registry in one answer.
The setup initContainer moves with them; it ran .58 by the same accident, and a
node whose init and main containers are different builds is a question nobody
should have to ask.

Consequence, on this file specifically: zood-mv is the only luxd StatefulSet on
RollingUpdate with podManagementPolicy Parallel, N=5 and alpha=4. A sync would
have restarted all five Zoo validators together onto ten-releases-old bytes,
and luxd waits for peers before it listens -- every node waiting for a node
that is also waiting.

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

deploy/zoo-mainnet/zood-mv.yaml

@@ -8,7 +8,7 @@ containerName: zood
 image:
   repository: ghcr.io/luxfi/node
   tag: v1.36.68
-  digest: sha256:175ef334c44575dc0f2a4abdaf0cc27b04e601a4494a93f4d3ff41db3170e1e1
+  digest: sha256:ebd16ed5b41fe04224925dc32b4b2a02993ca1cc4b177fb70dbd9e8de9af2c2e
   pullPolicy: IfNotPresent
 command:
 - /bin/sh
@@ -79,7 +79,7 @@ initContainers:
 - command:
   - /bin/sh
   - /scripts/init.sh
-  image: ghcr.io/luxfi/node:v1.36.58@sha256:175ef334c44575dc0f2a4abdaf0cc27b04e601a4494a93f4d3ff41db3170e1e1
+  image: ghcr.io/luxfi/node:v1.36.68@sha256:ebd16ed5b41fe04224925dc32b4b2a02993ca1cc4b177fb70dbd9e8de9af2c2e
   imagePullPolicy: IfNotPresent
   name: setup
   securityContext: