🚀 [Feature]: Make the Pester version configurable (default latest)

[Marius Storhaug (MariusStorhaug)]

Summary

Makes the Pester version a configurable input that defaults to latest, instead of baking a
major-version lock into the shared action (the approach in #70).

The framework's own dependency-management epic (PSModule/Process-PSModule#356) states the principle
directly: "Avoid staleness from over-locking… the default should track patches/minors, not freeze
forever," with locking modelled as a configurable policy layer (Latest / Lock Major / Lock Minor /
Lock Patch / Lock GUID) that is a per-consumer default with overrides. A hard [6.0.0,7.0.0) lock
compiled into the action applies one policy to every consumer and can only be changed by editing the
action — the wrong layer for the decision.

What changed

• New inputs (backward compatible; empty = latest):
  • Pester_Version — NuGet version-range syntax, e.g. [6.0.0,7.0.0) for any 6.x, or 6.4.0 for an exact version.
  • Pester_Prerelease — allow prerelease versions.
• src/init.ps1 / src/exec.ps1 install Pester using those inputs (default latest) instead of a hardcoded range.
• Deterministic install + import in Install-PSResourceWithRetry:
  • installs the newest version satisfying the constraint (or reuses an already-installed satisfying version),
  • imports that exact version into the global session state, so the Pester that Invoke-Pester runs is the resolved one — even though GitHub runners ship a preinstalled Pester. Previously the helper's Import-Module landed in the module's own scope and Invoke-Pester relied on PowerShell auto-loading the highest version on PSModulePath, which is the non-determinism behind the 2026-07-05 breakage.
  • The "Get test kit versions" output now reports the imported version (Get-Module) rather than the highest installed.
• This also addresses both Copilot review comments on ⚙️ [Maintenance]: Lock Pester to the 6.x major version #70 (import may load a different version; reported version may differ from the one used).

Why this is "more open"

• The action is a generic primitive again: default latest, restrict via input.
• The 6.x policy moves to one overridable place — a Process-PSModule setting — matching #356's policy-layer model (see follow-ups).
• Per-repo #Requires -Modules @{ Pester 6.x } in test files remains valid and complementary: it's the per-repo declaration / safety net (PowerShell errors if the installed Pester doesn't satisfy it), not a duplicate lock.

Validation

• Install-PSResourceWithRetry verified against the real gallery in isolated processes:
  • [5.0.0,6.0.0) → loads 5.9.0, [6.0.0,7.0.0) → loads 6.0.0, empty → loads latest (6.0.0).
• PSScriptAnalyzer (repo settings), markdownlint (repo config), YAML + PowerShell parse all clean.
• End-to-end coverage comes from the existing Action-Test.yml fixtures.

Follow-ups (not in this PR)

1. Process-PSModule: add an overridable PesterVersion setting and thread Pester_Version into the Invoke-Pester steps in Test-ModuleLocal.yml / Test-SourceCode.yml, then bump the pin to this action's next release. This is where the org-wide "6.x" default should live (overridable per repo).
2. The open per-repo "Require/Lock Pester 6.x in test files" PRs stay as the #Requires declaration layer.
3. Optional: a Pester_Guid input for Lock-GUID identity pinning (the remaining part of 🚀 [Feature]: Install the pinned Pester version — support #Requires-style version constraints on the Version input #68).

Relates to #68. Supersedes #70 (which can be closed in favour of this).