Bug Description

Show-ServyVersion passes --version as an argument without using the Command parameter of Invoke-ServyCli, while every other public function in the module passes a CLI subcommand via the Command parameter.

Actual Behavior

Show-ServyVersion (lines 244-250):

$invokeParams = @{
    Arguments    = @("--version")
    Quiet        = $Quiet
    ErrorContext = "Failed to get Servy CLI version"
}

Every other function uses the Command parameter, e.g. Show-ServyHelp:

$invokeParams = @{
    Command      = "help"
    Arguments    = if ($Command) { @($Command) } else { @() }
    Quiet        = $Quiet
    ErrorContext = "Failed to display Servy CLI help"
}

Why This Matters

• Inconsistent calling convention makes the code harder to maintain
• If Invoke-ServyCli is ever refactored to handle the Command parameter differently (e.g. logging, validation), Show-ServyVersion would be silently skipped
• If the CLI introduces a version subcommand in the future, updating would require changing the invocation pattern rather than just swapping a string

Suggested Fix

If the CLI supports servy-cli version as a subcommand:

$invokeParams = @{
    Command      = "version"
    Quiet        = $Quiet
    ErrorContext = "Failed to get Servy CLI version"
}

If the CLI only supports servy-cli --version (no subcommand), this is technically correct but worth documenting with a comment explaining why it deviates from the pattern:

# Note: --version is a global flag, not a subcommand, so we pass it as an argument
$invokeParams = @{
    Arguments    = @("--version")
    Quiet        = $Quiet
    ErrorContext = "Failed to get Servy CLI version"
}

Environment

• PowerShell module: Servy.psm1
• Affects: Show-ServyVersion function (lines 224-251)