fix(git-ext): honor explicit -Number 0 in PowerShell branch creation (parity with bash)

[Noor-ul-ain001]

Summary

The git extension's PowerShell branch-creation script silently ignored an explicit -Number 0. Because -Number is declared with a default of 0, the guards if ($Timestamp -and $Number -ne 0) and if ($Number -eq 0) could not tell an unset flag apart from a user passing -Number 0. A user asking for branch 000-... was routed into auto-detection and got the next sequential number instead.

This mirrors the same fix already landed for the core script in #3196 (scripts/powershell/create-new-feature.ps1) — the git-extension twin (extensions/git/scripts/powershell/create-new-feature-branch.ps1) still carried the bug.

Changes

• Replace both -eq 0 / -ne 0 checks with $PSBoundParameters.ContainsKey('Number'), which tests whether the flag was actually supplied — mirroring the bash twin's empty-string sentinel (BRANCH_NUMBER="", [ -z "$BRANCH_NUMBER" ] / [ -n "$BRANCH_NUMBER" ]).
• Add a parity regression test to both TestCreateFeatureBash and TestCreateFeaturePowerShell asserting --number 0 / -Number 0 yields 000-zero / FEATURE_NUM=000.

# Before: -Number 0 auto-detected the next number (e.g. 003-zero)
# After:  -Number 0 is honored → 000-zero
./create-new-feature-branch.ps1 -DryRun -Number 0 -ShortName zero "Zero feature"

Testing

Verified both twins manually (pwsh Core / real Git-for-Windows bash are gated by HAS_PWSH / requires_bash in CI):

Case	Bash	PowerShell
-Number 0	000-zero	000-zero
-Number 5	—	005-five
auto-detect (existing 001 spec)	001-auto	001-auto (parity)

🤖 Generated with Claude Code