fix(windows): resolve the captured PATH case-insensitively (fixes #232)

[ocensis]

Fixes #232. Also unblocks #234, which is a downstream symptom of the same empty PATH.

Root cause

Windows stores environment variable names with whatever casing the registry value name carries, and resolveShellEnvironment() returns a plain object keyed by that casing verbatim (parseEnvOutput, src/main/runtime/harness-runtime.ts). On a machine whose PATH value name is stored lowercase, the captured block arrives as path — and the exact-case read at the spawn-options site:

[pathKey]: environment[pathKey] ?? environment.PATH ?? ''

misses it, so the Harness spawns with Path="". The stray lowercase path carried along by the spread does not save it: Node's win32 spawn sorts env keys and case-insensitively dedupes keeping the first, and 'Path' sorts before 'path', so the empty explicit key wins. Measured end-to-end on Windows 11 (26200) / node v22: a child spawned through the current code with a lowercase-path block sees process.env.PATH === "". Every PATH-resolved tool call then fails with ENOENT — including powershell.exe for "Open configuration file" (#234).

process.env never shows this problem because Node makes it case-insensitive on win32 — but that behaviour does not survive a spread. ({...process.env}).Path is undefined on a lowercase-path machine even though process.env.Path is defined. buildProfilePluginCommandEnvironment (src/main/runtime/profile-plugin-command.ts) spreads its environment before reading Path/PATH exact-case, so plugin install/removal/repair subprocesses dropped the user's real PATH on the same machines: only the shim and bundled-node directories survived.

Fix

New helper resolveEnvironmentPath(environment, platform) in harness-runtime.ts:

• exact-case Path then PATH reads first (preserves existing behaviour for every input the current tests cover),
• then a case-insensitive scan, win32 only — POSIX keeps the exact read, since path is a genuinely different variable there,

used at both read sites. The write sites are untouched: writing Path/PATH next to the original lowercase key is safe because whichever key survives Node's win32 dedupe carries the same resolved value.

Verification

• npm test — full suite passes on Windows: 74 files, 556 tests.
• npm run typecheck — clean.
• Runtime measurement on a real Windows 11 box: rebuilt the capture → parse → spawn-options → spawn chain with a lowercase-path block; before the fix the child receives PATH="", after the fix it receives the full user PATH. (The lowercase value name itself comes from the reporter's PEB measurement in [Bug] Windows: Harness spawned with empty PATH when env block stores PATH as lowercase 'path' — user tools invisible to tool shells #232; I did not modify this machine's registry to reproduce that part.)

New regression tests:

• test/runtime.test.ts — buildHarnessSpawnOptions with a lowercase path block: every key spelling PATH in the returned env must carry the user's value.
• test/shell-environment-encoding.test.ts — helper-level casing matrix, including the POSIX exact-case guarantee.
• test/profile-plugin-command.test.ts — buildProfilePluginCommandEnvironment keeps the user PATH from a lowercase block on win32, and keeps path out of PATH on POSIX.