feat(windows): scaffolding pass for Windows support

[tannevaled]

Draft — Windows support scaffolding

Windows is an official pkgx target. This draft is a scaffolding pass that lets pkgm itself run on Windows; the open design questions raised in the original draft are now closed (see "Design answers" below).

⚠ End-to-end install on Windows is blocked upstream. A probe of all 842 top-level prefixes in dist.pkgx.dev (the bucket pkgx pulls package distributables from) finds zero packages with a windows/ subdir. So pkgm install <anything> on Windows hits Error: CmdNotFound("...") from libpkgx regardless of how complete pkgm's Windows port is. The CI smoke test exercises everything pkgm can verify without a working install (--version, ls on a fresh tree); end-to-end install will pass once upstream ships Windows artifacts.

What's in this PR

• standardPath() — Windows case returning baseline System32 / System32\Wbem; introduces PATH_SEP module constant (a literal ":" split would shred C:\ drive prefixes).
• install_prefix() — Windows resolves to %LOCALAPPDATA%\pkgm. Mirrors pkgxdev/setup's installer.ps1 ($env:LOCALAPPDATA\pkgx).
• ls() / outdated() — walk install_prefix().join("pkgs") on Windows instead of the hard-coded POSIX /usr/local/pkgs + ~/.local/pkgs pair.
• get_pkgx() — uses PATH_SEP and looks for pkgx.exe on Windows.
• symlink_with_overwrite() — Windows: hardlink for files (Deno.linkSync, no elevation needed on the same volume) with Deno.copyFileSync as last resort; dir symlinks via Deno.symlinkSync({ type: "dir" }) for the rare directory call site (relies on developer-mode being enabled — true on GHA Windows runners).
• create_v_symlinks() — early-return on Windows. The v1/v2/… aliases are a navigation convenience; canonical v<x.y.z> paths are what stubs and mirror_directory actually reference.
• Stub emission — when runtime env is present on Windows, emit a .cmd wrapper at <stem>.cmd that sets the env vars then execs the real binary. Delete the .exe hardlink first so PATHEXT doesn't shadow the wrapper. % in values escaped as %% (batch-file convention).
• Deno.chmod(0o755) guarded — throws on Windows.
• CI — new test-windows job, separate from the POSIX test matrix. Two smoke steps via explicit pkgx deno^2.1 run invocation: pkgm --version (validates pkgx-on-PATH + libpkgx imports + parseArgs floor) and pkgm ls (validates install_prefix() + the ls candidate-paths branch).

Design answers (modelled on what pkgx already does)

After surveying pkgxdev/pkgx + pkgxdev/setup:

Question	Answer	Where pkgx does it
System-wide install prefix	None — per-user only, %LOCALAPPDATA%\pkgm	pkgxdev/setup/installer.ps1 installs pkgx itself to $env:LOCALAPPDATA\pkgx
Elevation model	No UAC. Per-user only.	installer.ps1 writes to user-level PATH via [Environment]::SetEnvironmentVariable("Path", …, User) — never elevates
Stub format	.cmd files	pkgxdev/pkgx/crates/lib/src/utils.rs find_program() looks for .exe → .bat → .cmd extensions
Entrypoint	pkgm.cmd wrapper installed by pkgxdev/setup/installer.ps1 (mirror of the POSIX /usr/local/bin/pkgm shebang shim)	installer.sh already creates /usr/local/bin/pkgm as #!/usr/bin/env -S pkgx -q! pkgm; installer.ps1 would write a .cmd equivalent

The pkgm.cmd wrapper change belongs in pkgxdev/setup, not this PR.

Upstream gap discovered

While iterating, the CI's install hyperfine smoke step failed with Error: CmdNotFound("hyperfine") despite pkgm doing the right thing on its side. The v2 dist layout (under the v2/ prefix in the dist.tea.xyz bucket) shows 15 of 88 packages have Windows builds today — they're all the toolchain layer (bun.sh, cmake.org, curl.se, deno.land, git-scm.org, go.dev, libarchive.org, nasm.us, ninja-build.org, openssl.org, perl.org, python.org, rust-lang.org, sqlite.org, zlib.net). No application-layer packages (hyperfine, gum, fd, ripgrep, etc.) have Windows artifacts.

Per the maintainer's reply on pkgxdev/pkgx#607: the manifest infrastructure that produced these v2 Windows builds was rolled back about a year ago, and there's currently no pipeline producing new Windows artifacts. So pkgm install <app> on Windows is blocked on reviving (or replacing) that work upstream — not on anything pkgm itself can fix.

This PR is therefore "pkgm Windows-ready, waiting for the upstream build pipeline to come back online".

What's deliberately NOT in this PR

• shim() — also POSIX-shebang-based, needs .cmd/.ps1 variant.
• dev_stub_text() — generates POSIX shell with [ -x /usr/local/bin/dev ] || …; needs a Windows variant (or skip dev-mode integration in v1).
• Junctions via mklink /J as a fallback for create_v_symlinks on machines without developer mode.
• pkgm.cmd wrapper in pkgxdev/setup — separate PR to that repo.
• uninstall() Windows path normalisation — needs verifying once installs actually work.

Smaller open implementation questions

1. Stub shadowing: when both <name>.exe (the hardlink) and <name>.cmd would coexist, we currently delete the .exe and write only the .cmd (for pkgs with runtime env). Pkgs without runtime env keep the hardlinked .exe — meaning users with both env-wrapped and non-env pkgs see mixed extensions in bin/. Acceptable for v1.
2. Deno.copyFileSync fallback: only kicks in if Deno.linkSync fails (cross-volume etc.). Copy duplicates disk usage. Not a v1 concern.
3. %LOCALAPPDATA%\pkgm\bin on PATH: the install warns if missing but doesn't add it. pkgxdev/setup/installer.ps1 adds $env:LOCALAPPDATA\pkgx to the user PATH — pkgm install would benefit from the same treatment, also belongs upstream.

Test plan

lint, test (ubuntu-latest), test (macos-latest) should be green — verified locally with deno fmt --check, deno lint, deno check, and ./pkgm.ts i hyperfine + ./pkgm.ts ls smoke runs on macOS.

test-windows should be green via the two pkgm --version / pkgm ls smoke steps. End-to-end install can't be tested until the upstream dist gap closes.

sudo-install red is expected on this branch — that job's regressions are addressed in #86 and are independent of the Windows port.

Relationship to #86

Independent. Small conflicts expected in query_pkgx and get_pkgx — both branches add disjoint code paths.

References used

• pkgxdev/setup installer.ps1 — Windows install path + PATH manipulation.
• pkgxdev/pkgx crates/lib/src/config.rs — dirs_next::data_local_dir() resolves to %LOCALAPPDATA% on Windows.
• pkgxdev/pkgx crates/lib/src/utils.rs — find_program() .exe/.bat/.cmd extension lookup.
• pkgxdev/pkgx crates/cli/src/execve.rs — #[cfg(windows)] switch from execve to Command::spawn.
• dist.pkgx.dev S3 listing — confirmed the 842-prefix Windows gap.