fix(ci): pin PSDepend to 0.4.1 to fix PowerShell 5.1 bootstrap

[HeyItsGilbert]

Summary

The Run Tests (PowerShell 5.1) CI job has been failing on every PR (e.g. #468, #469, #470) during build.ps1 -Bootstrap with:

PSDepend\0.3.8\Private\SemanticVersion.ps1: Cannot add type.
The type name 'System.Management.Automation.SemanticVersion' already exists.

Root cause

PSDepend 0.3.8 ships an unguarded Add-Type for its Windows PowerShell 5.1 SemanticVersion polyfill:

if ($PSVersionTable.PSVersion.Major -lt 6) {
  Add-Type -TypeDefinition $code
}

On PS 5.1, System.Management.Automation.SemanticVersion is not a built-in type, so this runs. When PSDepend is imported a second time in the same session — which the bootstrap triggers because PSDepend is pinned as a dependency of itself in requirements.psd1 — the Add-Type throws, since the type already exists in the AppDomain. PowerShell 6+ is unaffected: the type is built in, so the guard short-circuits.

PSDepend 0.4.1 (newly released) adds the missing existence guard, making the polyfill idempotent:

if ($PSVersionTable.PSVersion.Major -lt 6 -and -not ('System.Management.Automation.SemanticVersion' -as [type])) {
  Add-Type -TypeDefinition $code
}

Fix

Bump the PSDepend pin in requirements.psd1 from 0.3.8 → 0.4.1.

Reproduction / verification

Reproduced on local Windows PowerShell 5.1 (5.1.26100) by pre-defining the type then dot-sourcing each version's SemanticVersion.ps1:

PSDepend	Result
0.3.8	❌ Cannot add type. The type name 'System.Management.Automation.SemanticVersion' already exists.
0.4.1	✅ no-op (guard skips Add-Type)

CI will confirm the PS 5.1 job goes green on this PR.

🤖 Generated with Claude Code