Windows test run pollutes (and can clobber) the real ~/.insta/config.json — HOME-override isolation is a no-op on Windows

[tonychang04]

What

Running the unit suite on Windows pollutes — and can destroy — the developer's real ~/.insta/config.json.

Proven on a real windows-latest runner (run 32407886883, job unit-tests-windows): test/ensure-skills.test.ts failed expecting InsForge/insta-skills but got InsForge/insta-skills#devel — on a fresh runner that had never touched staging.

Why

• src/config.ts resolves GLOBAL_DIR from os.homedir() at import time.
• test/env-switch.test.ts isolates by setting process.env.HOME to a temp dir (+ vi.resetModules()). That works on macOS/Linux, but on Windows os.homedir() reads USERPROFILE, so the override is a no-op and every write in that suite lands in the runner's real %USERPROFILE%\.insta\config.json — including tests that persist a staging apiUrl.
• test/ensure-skills.test.ts does no HOME isolation at all; installSkills → resolveEnv() reads whatever the real config says. After the env-switch suite has polluted it → #devel → assertion failure. (This is also why the ensure-skills/setup tests fail on any dev machine whose real config points at staging, on any OS.)

Impact

• Windows CI for the unit suite is flaky/false-failing (product paths are fine — the setup-agent e2e passed on the same runners in both PowerShell and cmd).
• A contributor running npm test on Windows gets their real ~/.insta/config.json overwritten with test data — logged-out at best, silently re-pointed at a test apiUrl at worst.

Fix sketch

1. env-switch.test.ts: set USERPROFILE (and HOME) to the temp dir in beforeEach, restore both in afterEach.
2. ensure-skills.test.ts (and the setup tests that hit resolveEnv): isolate the same way, or inject the skills spec instead of reading the machine's config.
3. Optionally make config.ts read the home dir lazily via a function so tests don't depend on vi.resetModules() import-time tricks.

Found while e2e-verifying npx -y insta setup agent (#110) on Windows.