fix(zdeploy): the container-side version read no longer races the app restart

It was gated behind a single probe that ran immediately after the container
was restarted, so the probe hit a port that was not listening yet, the flag
stayed false for the whole run, and the check fell back to the public proxy.

That answers from whichever vhost matches the Host header, so a deploy that
had worked was reported as failing -- against another service's version
entirely. Silent and wrong, which is the combination worth removing.

viaProxy/upstream is configured explicitly to read a version, so a failure
means "not up yet", and the retry loop already handles that: the JSON parse
throws on an empty read, the catch waits and tries again. Trusting the
config removes the race.

The port mechanism keeps its probe -- verify.port is not necessarily a
version endpoint, so there the probe answers a real question.

CHECKSUMS.txt regenerated; CHANGELOG.md and its plain-text twin carry the
entry. Pester: 231 passed, 0 failed.

CHANGELOG.md

@@ -10,6 +10,17 @@ Notable changes to the Evomedia.net Token Savers.
 
 ## Unreleased
 
+### Fixed
+- **The container-side version read no longer races the app's restart** —
+  it was gated behind a single probe that ran immediately after the
+  container was restarted, so the probe hit a port that was not listening,
+  the flag stayed false for the whole run, and the check fell back to the
+  public proxy. That answers from whichever vhost matches the Host header,
+  so a deploy that had worked was reported as failing against *another
+  service's* version. The read is used whenever it is configured now, and
+  the retry loop handles "not up yet", which it already did.
+
+
 ### Changed
 - **`zversion bump` is once per *release*, not once per PR** — the usage text
   and the `bump` help line both said "one per PR, one per defect fix". The

CHANGELOG.txt

@@ -9,6 +9,17 @@ Notable changes to the Evomedia.net Token Savers.
 
 Unreleased
 ----------
+Fixed
+- The container-side version read no longer races the app's restart. It
+  was gated behind a single probe that ran immediately after the container
+  was restarted, so the probe hit a port that was not listening, the flag
+  stayed false for the whole run, and the check fell back to the public
+  proxy. That answers from whichever vhost matches the Host header, so a
+  deploy that had worked was reported as failing against another service's
+  version. The read is used whenever it is configured now, and the retry
+  loop handles "not up yet", which it already did.
+
+
 Changed
 - zversion bump is once per RELEASE, not once per PR - the usage text and
   the bump help line both said "one per PR, one per defect fix". The build

CHECKSUMS.txt

@@ -8,7 +8,7 @@ e35d91a175c29dcbe285b55397371a584000aab9ae3de6839f8b31def1d9dfd0  token-count.ps
 49d48d55bab1b9ee5bc66cb96340a20fa50241b6a3558d4c518db3e06d4553e6  zchecksums.cmd
 e0cbc6f263c129d89e87e8e7356fb256f59f21a6a4b209e191e7c70a3611286e  zchecksums.ps1
 bd5563bf74b83423aca49a56450f3712a9aec3d6a59f8b7862d5c5988c6defd2  zdeploy.cmd
-4a55ed714358b910fd2f326a6222e2ebaa99a1321df025a19edb6bbe0da13e76  zdeploy.ps1
+22d13a924c2358fda4d650fcc43f0ace91d8c8ad96faa10aef8c10787090faf9  zdeploy.ps1
 1883d7307682c68bf3786203f54e9abfe12fcb09e3856190e3a7af5fffb2a16a  zec2.cmd
 f9d0406f97e19303d8b368df8aaf70e5011a99703f67ca7b2b526e82a3c68789  zec2.ps1
 e1da88e4af6d5c88cc95231dc544ef29440d306e70739d0ba1f72795d359778d  zec2_rotatekeys.cmd

zdeploy.ps1

@@ -263,11 +263,17 @@ function Wait-VerifyApiBuild {
     # header - so a container with no public route gets another site's
     # version back. See Get-ServerSideVersionCommand.
     $execCmd = Get-ServerSideVersionCommand -Proj $Proj
-    $useExec = $false
-    if ($execCmd) {
-        $probe = (ssh @SSH_OPTS -i $PEM_KEY $SSH_TARGET $execCmd | Out-String).Trim()
-        if (Get-LabelFromVersionJson $probe) { $useExec = $true }
-    }
+    # No pre-probe. viaProxy/upstream is configured EXPLICITLY to read a
+    # version, so a failure here means "not up yet" - which is what the retry
+    # loop below exists for.
+    #
+    # Gating on one probe made the app's own restart a race, and losing it
+    # was silent AND wrong: this runs right after the container is restarted,
+    # so the probe hit a port that was not listening, $useExec stayed false
+    # for the whole run, and the check fell back to the proxy - which answers
+    # from whichever vhost matches the Host header, i.e. another service's
+    # version. The deploy had worked; only the verification was lying.
+    $useExec = [bool]$execCmd
     if ($useExec) {
         Write-Host "  Asking on server: $($Proj.verify.upstream) (via $($Proj.verify.viaProxy))" -ForegroundColor DarkGray
     }