Pester version pin in requirements.psd1 is not honored

[tablackburn]

requirements.psd1 pins Pester = '6.0.0', and the suite does not run on 6.0.0. Observed
locally today across several runs, including the full ./build.ps1 -Task Test:

Pester v6.1.0

Installed on that machine: 6.1.0, 6.0.1, 6.0.0, 5.7.1, 3.4.0. The newest wins regardless of the
pin.

Mechanism

Pester 6 runs discovery for each test file separately, and resolving Describe triggers
PowerShell module autoloading. Autoloading always selects the highest installed version,
overriding whatever version was imported beforehand. So a pin below what is already present on
the machine — or baked into a CI runner image — cannot be honored.

This is now written down in instructions/powershell.instructions.md as of the AIM 0.12.0 sync
(#171), which recommends Version = 'latest' for Pester specifically, and normal pinning for
everything else.

Why it matters here, and why it is not urgent

The pin exists to make runs reproducible. It does not, so "the suite passes on Pester 6.0.0" is
an assertion CI has never actually tested — it tests whatever the runner has. Nothing is broken
today: the suite passes on 6.1.0, and the versions are close.

The sharper edge is the compatibility matrix. requirements.pester-matrix.psd1 pins
PesterLegacy = 5.9.0 so Test-PSBuildPester is verified against both supported majors, and
Test-PSBuildPester.tests.ps1 selects the newest installed of each major at discovery:

$newestOfMajor = Get-Module -Name 'Pester' -ListAvailable |
    Where-Object { $_.Version.Major -eq $majorVersion } |
    Sort-Object -Property 'Version' -Descending |
    Select-Object -First 1

That is already "newest of each major" rather than "the pinned version", so the matrix is
honest about what it tests — but it means the 5.x leg silently disappears on a machine where no
Pester 5 is installed, and the number of legs varies by environment. Worth confirming both legs
actually run in CI rather than assuming.

Options

1. Change Pester to latest in requirements.psd1, matching the guidance, and accept that the
   version follows the runner.
2. Keep the pin but make it real, by importing the pinned version explicitly before invoking
   Pester and failing loudly if a different one loads.
3. Keep the pin as documentation of a floor, and state in the file that it is a minimum rather
   than a lock.

Option 1 is the guidance and the least machinery. Option 2 is the only one that delivers what
the pin currently promises.

Done when

requirements.psd1 and the actual runtime agree, and CI reports which Pester version it ran, so
the next divergence is visible rather than inferred.