ci: cover Pester 4 and both supported Windows Server releases

[tas50]

Integration on this repo is already real — it stands up WinRM on the runner and drives kitchen verify against it. What it does not do is cover the branch that most needs covering.

#invoke_pester_scriptblock emits two different dialects, chosen on the SUT from the version it finds:

if ($PesterModule.Version.Major -le 4) { ... $result = Invoke-Pester @invokePesterParams }
else { ... $result = Invoke-Pester -Configuration $PesterConfig }

Integration only ever ran whatever Pester the gallery currently ships, so the Pester 4 half — the Get-Command Invoke-Pester parameter intersection, New-PesterOption, OutputFormat NUnitXml — has never actually executed in CI.

What this adds

• A pester4 suite in kitchen.windows.yml, pinned with pester_install.MaximumVersion, plus tests/integration/pester4/. Its assertions match the default suite's, written to the syntax Pester 4 and 5 share, and the first one asserts the run really happened under Pester 4 — a pin that quietly stopped working would otherwise just re-test the Pester 5 path.
• A step that deletes the runner image's machine-wide Pester 5 before that suite. Import-Module Pester takes the highest version on PSModulePath, so without this the pin has no effect. The step throws if any Pester 5 survives, so a failure points at the setup rather than at a confusing assertion later.
• windows-2022 and windows-2025 instead of windows-latest alone.
• The Ruby dimension trimmed to the gemspec floor (3.1) and current (4.0). lint.yml still runs the unit specs on 3.1, 3.4 and 4.0, so nothing is lost, and 2 suites x 2 OSes x 2 Rubies keeps this at 8 jobs rather than 18.
• The platform is renamed windows-latest -> windows, since the runner version is now the matrix's job. Instances are default-windows and pester4-windows, and results are uploaded per matrix cell.

Note the repeated defaults in the pester4 suite's pester_install. That key is replaced wholesale rather than merged, so pinning MaximumVersion alone would silently drop SkipPublisherCheck, Force and ErrorAction, and the install would fail against the in-box Pester 3.4.0.

CONTRIBUTING.md is updated to describe both suites and how to run them against your own Windows box.

Verification

Locally, the config resolves and the new PowerShell parses:

$ KITCHEN_YAML=kitchen.windows.yml bundle exec kitchen list
Instance         Driver  Provisioner  Verifier  Transport  Last Action    Last Error
default-windows  Proxy   Shell        Pester    Winrm      <Not Created>  <None>
pester4-windows  Proxy   Shell        Pester    Winrm      <Not Created>  <None>

$ yamllint .github/workflows/integration.yml kitchen.windows.yml   # clean
$ npx markdownlint-cli2 CONTRIBUTING.md
Summary: 0 issues in 0 files

$ bundle exec cookstyle --chefstyle
11 files inspected, no offenses detected

$ bundle exec rake test
149 runs, 293 assertions, 0 failures, 0 errors, 0 skips
Tests Passed: 17, Failed: 0, Skipped: 0

The workflow itself can only be proven by running it, which this PR does.