Align the PowerShell version contract with runtime requirements

[MariusStorhaug]

Context

The module artifact generated from #100 declares PowerShellVersion = '7.0', but the changed installation path uses runtime features introduced after PowerShell 7.0.

Observed behavior

src/functions/public/Install-NerdFont.ps1 uses a clean block, introduced in PowerShell 7.3. src/functions/private/Invoke-NerdFontDownload.ps1 calls HttpContent.ReadAsStreamAsync(CancellationToken), which requires .NET 5 or later; PowerShell 7.0 uses .NET Core 3.1. The current cross-platform CI validates the current runner PowerShell version, not the generated manifest's minimum version.

Expected behavior

The generated manifest, README support statement, implementation, and CI matrix describe and validate the same minimum supported PowerShell runtime.

Reproduction

1. Build the module artifact from the 🪲 [Fix]: Font installs handle variants and transient failures #100 branch.
2. Inspect NerdFonts.psd1 and observe PowerShellVersion = '7.0'.
3. Import or execute the changed installation path with PowerShell 7.0.
4. Observe that the clean block cannot be parsed and the cancellation-token stream overload is unavailable.

Environment

PowerShell 7.0 on .NET Core 3.1. The branch otherwise passes current-LTS CI on Windows, macOS, and Linux.

Regression

Introduced by the installation cleanup and downloader changes in #100. The repository README already states that the supported runtime is the latest PowerShell LTS.

Workaround

Use the latest PowerShell LTS release.

Acceptance criteria

• The generated manifest and README state the same minimum supported PowerShell version.
• Every syntax construct and .NET API used by the module is available in that minimum version.
• CI exercises the declared minimum version or the generated contract is raised to the version already exercised by CI.
• Current-LTS behavior remains validated on Windows, macOS, and Linux.

Technical decisions

Choose either backward-compatible implementation changes or an explicit increase to the generated minimum version. Do not retain a manifest floor that the module cannot import or execute.

Implementation plan

• Add a failing minimum-runtime compatibility check for the generated module.
• Align the implementation or generated manifest with the selected minimum runtime.
• Update the README support statement if the supported floor changes.
• Validate the generated module on the declared minimum and current LTS.