fix: delete management/ncp.ps1 - it shadowed the ncp.cmd PATH shim

PowerShell resolves ExternalScript (.ps1) ahead of Application (.cmd), and both
lived in the directory the installer puts on PATH -- so in PowerShell `ncp` ran
the .ps1 and was execution-policy-bound again, the exact thing the .cmd exists
to avoid. Its other justification (giving ncp to pwsh on Linux) stopped being
true once /usr/local/bin/ncp existed: pwsh runs a PATH symlink to a shell script
as an Application. A test now prevents the file coming back.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

install-windows.ps1

@@ -127,7 +127,8 @@ Write-OK "Web UI built (interface\web\dist)"
 # management\ncp.cmd goes on the machine PATH rather than a `function ncp` in the
 # PowerShell profile. Three reasons the profile route kept biting:
 #   1. Execution policy defaults to Restricted, which blocks the profile itself -
-#      so the function was never defined, and ncp.ps1 could not have run anyway.
+#      so the function was never defined, and the .ps1 it called could not
+#      have run anyway.
 #   2. Profiles are a PowerShell thing. cmd, Win+R, Task Scheduler and .lnk
 #      targets all reported "ncp is not recognized".
 #   3. We are elevated here, so $PROFILE is the ADMIN's profile - the whole