ci: pin Pester by exact version everywhere it is installed or imported

Pester was installed with -MinimumVersion 5.0 and no ceiling in the CI job
image, both install steps in unit-tests.yml, and both Import-Module calls, plus
the suite's own import inside the container. The image is rebuilt on every CI
run and Pester is installed fresh on every unit-test run, so PSGallery chose the
version — a new major could reach the required PR checks with no commit here,
surfacing as unexplained test breakage on whichever PR ran next.

It had already happened. Steps named "Install Pester 5" were resolving 6.1.0 on
both legs, because Pester 6 declares PowerShellVersion 5.1 and so installs on
Windows PowerShell too. Nothing broke — the suite uses only constructs common to
5 and 6, and runs 1566/0 under 6.1.0 with no deprecation warnings — but nobody
chose it. The step names are corrected; they had been describing an install that
stopped happening some time ago.

Pinning the install alone is not enough, in two ways review found:

An unset variable does not fail. -RequiredVersion accepts an empty value and
degrades to "latest" for Install-Module and to "any" for Import-Module, both
exiting 0, so a renamed or dropped env key would silently restore the float this
commit removes. A guard step now fails the job instead.

The point of use was still floored. run-integration.sh imported the suite's
Pester with -MinimumVersion 5.0, so a second Pester reaching PSModulePath would
win regardless of what was installed. The Dockerfile now promotes the ARG to ENV
so the version is discoverable at runtime, and that import is pinned to it.

The pin lives in two files, so shell-selfchecks asserts they agree — split-brain
between the workflow and the image is precisely the unexplained breakage this is
meant to prevent. CONTRIBUTING.md and CLAUDE.md are updated too; the contributor
instructions were a third floating install site.

Recorded as an amendment to D017 — the same principle as the nested PVE package
pin, applied to the lane's own tooling.

tests/Dockerfile.test

@@ -36,12 +36,22 @@ RUN if [ "$(dpkg --print-architecture)" = "amd64" ]; then \
         && ln -s /root/.dotnet/tools/pwsh /usr/local/bin/pwsh; \
     fi
 
-# Install Pester and prepare module directory
+# Install Pester and prepare module directory.
+# Pinned, not floored: this image is rebuilt on every CI run, so a version range
+# lets a new Pester major reach the gating lane with no commit to this repo.
+# Bump deliberately, the way D017 treats the nested PVE package set.
+ARG PESTER_VERSION=6.1.0
 RUN pwsh -NoProfile -Command \
-       'Set-PSRepository -Name PSGallery -InstallationPolicy Trusted; \
-        Install-Module -Name Pester -MinimumVersion 5.0 -Scope AllUsers -Force' \
+       "Set-PSRepository -Name PSGallery -InstallationPolicy Trusted; \
+        Install-Module -Name Pester -RequiredVersion $PESTER_VERSION -Scope AllUsers -Force" \
+    && pwsh -NoProfile -Command \
+       "if (-not (Get-Module -ListAvailable Pester | Where-Object Version -eq '$PESTER_VERSION')) { throw 'Pester $PESTER_VERSION not installed' }" \
     && mkdir -p /usr/local/share/powershell/Modules/PSProxmoxVE
 
+# Promoted to ENV so the suite can pin its import too — the install pin alone
+# does not bind the point of use if a second Pester ever reaches PSModulePath.
+ENV PESTER_VERSION=$PESTER_VERSION
+
 WORKDIR /repo
 CMD ["pwsh", "-NoProfile"]
 

tests/infrastructure/scripts/run-integration.sh

@@ -565,7 +565,11 @@ cmd_test() {
         pwsh -NoProfile -Command "
             \$PveVersion = '$v'
             \$TestFilter = '$pester_filter_arg'
-            Import-Module Pester -MinimumVersion 5.0
+            \$pesterVersion = \$env:PESTER_VERSION
+            if ([string]::IsNullOrWhiteSpace(\$pesterVersion)) {
+                throw 'PESTER_VERSION is not set — refusing to import whichever Pester happens to be present'
+            }
+            Import-Module Pester -RequiredVersion \$pesterVersion
             \$config = New-PesterConfiguration
 
             if (\$TestFilter) {