fix: run install lifecycle scripts on Windows

[Agnik47]

Problem

npm ci / npm install fails on Windows before any dependency work finishes:

npm error command C:\WINDOWS\system32\cmd.exe /d /s /c [ -d src ] && npm run build || true
'[' is not recognized as an internal or external command, operable program or batch file.
'true' is not recognized as an internal or external command, operable program or batch file.
npm error code 1

npm runs lifecycle scripts through the platform shell — cmd.exe on Windows — and prepare was POSIX sh. cmd.exe has neither [ nor true, so the script exits 1 and takes the install with it. The tree is left unbuilt: no dist/, and no generated hosted-contract.json.

That last artifact is the expensive part. It is gitignored and produced only by npm run build, so without it readInstalledHostedContractIdentity() cannot resolve and every hosted surface fails. On this machine the unit suite went from 237 failures to 40 once the build actually ran; the remaining 40 are unrelated and pre-existing (symlink EPERM without Developer Mode, /tmp paths — #476 — and timing flakes).

CI does not catch this: GitHub's windows-latest runner happens to resolve a POSIX shell for npm scripts, so prepare succeeds there. It only bites contributors on an ordinary Windows install.

Fix

prepare moves into scripts/prepare.mjs — plain Node, matching every other script in this package (clean-dist.cjs, copy-yaml.cjs, postinstall.js, check-*.mjs). It keeps both halves of the original intent:

• skip the build when there is no source tree to compile (a published tarball ships only dist/);
• never fail the install, whatever the build does.

The same || true idiom was silently inert on Windows in the other two install lifecycle scripts — if postinstall.js had ever exited non-zero there, 'true' is not recognized would have failed the install rather than rescuing it. Those guards move into the scripts themselves: postinstall swallows its own errors, and preuninstall wraps the daemon-shutdown probe in try/catch. Both already tolerated failure on POSIX; now they do so everywhere.

build, compile and the other developer scripts are untouched — && chaining works fine in cmd.exe. What breaks is chaining to a shell builtin it does not have.

Regression coverage

src/lifecycle-scripts.test.ts (11 tests):

• a lint over preuninstall, postinstall, prepare and prepublishOnly that rejects POSIX-only syntax — test brackets, chaining to true/false/:, command substitution, inline VAR= prefixes. Checked against the three old strings: it flags every one of them and passes all four new ones, so it is not vacuous.
• the prepare script's three paths — skip when there is no src/, build when there is, and warn-but-succeed when the build fails — exercised by copying the real script into a throwaway package so it resolves that directory as its root. No test-only override needed.

Verification

• npm run typecheck — clean.
• npx vitest run --project unit src/lifecycle-scripts.test.ts — 11 pass.
• npx vitest run --project unit — 3437 pass / 40 fail, down from 237 fail; no new failures.
• A scratch package with the old script shape fails npm install with exit 1 on Windows and succeeds with the new one.
• npm run prepare now completes the real build on Windows and regenerates cli-manifest.json and hosted-contract.json.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[Agnik47]

The failing check here is a pre-existing flake, not something this PR introduces.

Unit tests (windows-latest, shard 1/2) failed on two tests in src/site-memory/checkpoint.test.ts, which this PR does not touch:

Error: Test timed out in 5000ms.
Error: EBUSY: resource busy or locked, rmdir 'C:\Users\RUNNER~1\AppData\Local\Temp\webcmd-checkpoint-t05DZ4\.webcmd\sites'

Everything else is green — 1536 passed, plus Build (windows-latest), both Ubuntu and macOS shards, Unit tests (windows-latest, shard 2/2), and Bun.

Evidence that it is unrelated:

• The identical failure — same test file, same EBUSY … \.webcmd\sites signature — hit Fix SLAB full-parity session orchestration #481's branch the day before this PR was opened, and that shard has gone red on main several times recently.
• checkpoint.test.ts drives real git through execFile into temp directories. It reads nothing from package.json, the npm lifecycle, or any of the four files changed here.

I tracked down the cause and opened #484 for it: the test overruns vitest's 5s default under parallel load on Windows, vitest aborts it mid-git, and cleanup then fails on the handles the aborted child still holds — one cascade reported as two errors.

This PR needs a re-run to go green; I do not have the permissions to trigger one.