fix(powershell): handle unavailable Update-Module

[niStee]

What does this PR do

Closes #1443.

This changes the PowerShell module update step to avoid passing -Force to Update-Module when --yes is used. Instead, it passes -Confirm:$false and conditionally adds AcceptLicense when the installed Update-Module supports it.

It also checks whether PowerShellGet can provide Update-Module before running the update. If Update-Module is unavailable or cannot be loaded, Topgrade now prints a warning and marks the step as skipped instead of failing with a command-not-found error or reporting OK after doing no update.

This helps Windows PowerShell 5.1 setups where PowerShellGet/PackageManagement are broken, blocked by cloud-backed module folders, or otherwise cannot be autoloaded.

Standards checklist

• The PR title is descriptive
• I have read CONTRIBUTING.md
• Optional: I have tested the code myself, with the relevant tools installed. If yes, add Topgrade's output of the relevant steps.
• If this PR introduces new user-facing messages they are translated

AI involvement

I used AI assistance while investigating the PowerShell behavior, drafting the code change, and running local checks. I reviewed the changes myself before submitting.

[niStee]

Tested with:

• cargo fmt --check
• cargo test
• cargo clippy --all-targets -- -D warnings
• Manual PowerShell checks with PowerShell 7, Windows PowerShell 5.1, gsudo, and native Windows sudo.

[GideonBear]

Looks fine to me, thanks!

[GideonBear]

@atoerien any chance you can review this?

[atoerien]

Looks good, tested working on macOS, but I haven't been able to test on Windows yet.

Just have a couple relatively minor comments.

[niStee]

Latest push addresses the PowerShell review feedback:

• moved the Update-Module command probe into Powershell::has_command
• dry-run now performs the read-only availability check without sudo
• shortened the generated PowerShell variables
• added/updated focused tests for the command builder and PowerShell probe string

Validated on Linux:

• cargo fmt --check
• cargo check
• cargo test powershell
• cargo clippy --all-targets -- -D warnings
• git diff --check

Windows runtime testing is still pending. Please hold merging until I test PowerShell 7 / pwsh and Windows PowerShell 5.1 locally.

[niStee]

Latest push addresses the remaining PowerShell review feedback:

• Powershell::has_command now passes the command name as a param($command) argument instead of interpolating/quoting it into the script.
• The availability probe now uses the same use_sudo setting in dry and wet runs, so dry-run and real runs check the same execution path.
• The probe is still read-only and executes during dry-run via .always(), while the actual Update-Module command remains dry-run gated by the normal executor behavior.

Validated locally:

• cargo fmt --check
• cargo check
• cargo test
• cargo clippy --all-targets -- -D warnings
• cargo build
• git diff --check

Windows/PowerShell runtime probes:

• PowerShell 7 / pwsh: Update-Module probe returns true
• Windows PowerShell 5.1 on my current broken module setup: probe exits 0 with no output, so Topgrade will skip cleanly
• Windows PowerShell 5.1 with PSModulePath removed: probe exits 0 with no output, so Topgrade will skip cleanly
• Windows PowerShell 5.1 through gsudo: probe exits 0 with no output
• Windows PowerShell 5.1 through native Windows sudo: probe exits 0 with no output
• Elevated PowerShell 7 through gsudo: probe returns true

CI is green on the latest commit (1567e86). Ready for review/merge from my side.

[atoerien]

Just two final nits, otherwise all good - tested everything seems to be working on Windows with pwsh and powershell (both with a working Update-Module)

[niStee]

@atoerien thx for the feedback.