fix: restore Windows PowerShell 5.1 import compatibility

[tablackburn]

Summary

PowerShellBuild 0.8.0 fails to import under Windows PowerShell 5.1 (Desktop). Get-PSBuildCertificate (added in #92) used the PowerShell 7+-only ternary operator; since the module loader dot-sources every Public/*.ps1 at import, the parse failure broke import of the whole module on 5.1 — even though the manifest still declares PowerShellVersion = '3.0'.

Fix

• Ternary → if/else expression in Get-PSBuildCertificate (5.1-safe; identical PS7 behavior).
• $IsWindows guard made 5.1-safe using the repo's existing idiom ($null -ne $IsWindows -and -not $IsWindows, as in Build-PSBuildUpdatableHelp). On Desktop edition the automatic variable is absent and the platform is always Windows.

Audit

Swept all .ps1/.psm1/.psd1 under PowerShellBuild/, build/, and tests/ (and re-parsed every module file on a real 5.1 engine) for PS7-only constructs (ternary, ??/??=, ?./?[ ], &&/||, clean{}, -Parallel, Core-only $Is* vars, Core-only cmdlets/types). The two issues in Get-PSBuildCertificate.ps1 were the only real incompatibilities.

Guardrails

• PSScriptAnalyzer compatibility rules (PSUseCompatibleSyntax/Commands/Types) enabled in ScriptAnalyzerSettings.psd1, targeting Windows PowerShell 5.1 (Desktop) and PowerShell 7. PSUseCompatibleSyntax checks the target language version regardless of the engine it runs on, so it catches a ternary even from pwsh. Two documented false positives are suppressed with justifications (Get-ChildItem -CodeSigningCert provider dynamic parameter; Invoke-Pester -Configuration from the required Pester 5+).
• Analyze build task fails on any compatibility violation (these rules are Warning-severity, which the existing Error-only gate would not catch).
• New import-smoke CI job parses and imports the module on the real Windows PowerShell 5.1 engine (shell: powershell).

Verification

• Parse + dot-source + Import-Module on real Windows PowerShell 5.1: clean (original failed with the documented parse errors).
• PSScriptAnalyzer with the new settings: 0 compatibility findings; confirmed it flags a reintroduced ternary.
• psake Test (Analyze + Pester) on pwsh 7: Analyze clean of compatibility issues; 304 Pester tests pass, including all of Get-PSBuildCertificate.tests.ps1.

Support contract

Per maintainer direction, the manifest (PowerShellVersion/CompatiblePSEditions) is left unchanged in this PR; the code is fixed to comply with the existing 5.1/Desktop contract. Formalizing the declared floor is tracked for the v1.0.0 roadmap (#120).

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR restores Windows PowerShell 5.1 (Desktop) module import compatibility by removing PowerShell 7-only syntax from a public function that is dot-sourced during module import, and adds guardrails to prevent similar regressions via ScriptAnalyzer gating and a 5.1 import smoke test.

Changes:

• Replace PowerShell 7+ ternary usage and make $IsWindows checks safe on Windows PowerShell 5.1 in Get-PSBuildCertificate.
• Enable PSScriptAnalyzer compatibility rules and fail the build on any PSUseCompatible* findings.
• Add a CI job that parses and imports the module under Windows PowerShell 5.1.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
psakeFile.ps1	Makes Analyze fail the build on PSUseCompatible* findings while preserving existing error/warning handling.
PowerShellBuild/ScriptAnalyzerSettings.psd1	Enables PSUseCompatibleSyntax/Commands/Types targeting Windows PowerShell 5.1 and PowerShell 7.
PowerShellBuild/Public/Test-PSBuildPester.ps1	Suppresses a documented PSUseCompatibleCommands false positive for Invoke-Pester -Configuration.
PowerShellBuild/Public/Get-PSBuildCertificate.ps1	Removes PS7-only ternary usage and makes the Windows-only guard safe when $IsWindows is absent on 5.1.
CHANGELOG.md	Documents the 5.1 import fix and the newly added compatibility guardrails.
.github/workflows/test.yml	Adds a Windows PowerShell 5.1 parse+import smoke-test job to CI.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tablackburn]

Added the 0.8.1 release bump to this PR: promoted the Unreleased CHANGELOG entries to ## [0.8.1] 2026-06-03 and bumped ModuleVersion to 0.8.1 (backward-compatible patch). Verified the changelog↔manifest version-match and Test-ModuleManifest locally. After merge, I'll tag/publish v0.8.1.

[HeyItsGilbert]

Approved with a suggestion to run the tests in 5.1 as well (vs just an import test).

[github-actions]

Test Results

    4 files    376 suites   20s ⏱️
  316 tests   314 ✅  2 💤 0 ❌
1 264 runs  1 217 ✅ 47 💤 0 ❌

Results for commit aa6283d.

♻️ This comment has been updated with latest results.

[tablackburn]

Heads-up on the shared-workflow dependency: the Windows PowerShell 5.1 coverage lives upstream in psake/.github#7, which adds a test_powershell job (full build.ps1 -Task Test -Bootstrap under Desktop on windows-latest) to the shared ModuleCI.yml.

State of play:

• This PR already calls the shared workflow at @main, so its current CI runs lint + the PowerShell 7+ matrix + publish — but not the 5.1 job yet, because psake/.github@main doesn't have it until Existing Module Version Check Very Strict #7 merges.
• Once ci: run module tests on Windows PowerShell 5.1 in shared workflow .github#7 merges, the next CI run here picks up Run Tests (Windows PowerShell 5.1) automatically — no change needed on this branch.
• Existing Module Version Check Very Strict #7 deliberately leaves the existing test job id/name untouched, so no required-status-check rename is needed.
• There's a TODO in test.yml to consider pinning psake/.github to a tag/SHA (instead of @main) after Existing Module Version Check Very Strict #7 lands.