fix(install): recover CoDev Code's native binary instead of dead-ending the wizard

[quickbeard]

What users hit

codevhub install fails on the CoDev Code row and the wizard stops there:

Installing packages
✗ Failed to install codev-code: installed but 'codev' fails: Starting CoDev Code...
This version of C:\Program Files\nodejs\node_modules\codev-code\bin\codev.exe is not
compatible with the version of Windows you're running. Check your computer's system
information and then contact the software publisher.
✓ Installed @colbymchenry/codegraph

Nothing follows. That is not a rendering artifact — CoDev Code is locked into
every selection by ToolSelect, so its failure empties handleInstallDone's
survivor set and SetupApp parks on the terminal install-failed phase. The
user cannot reach configure, and re-running install reproduces it exactly.

Why

codev-code ships the same shape as Claude Code: a placeholder at
bin/codev.exe plus a postinstall.mjs that copies the real ~170 MB binary out
of a platform-specific optionalDependency. When the postinstall doesn't place
it, the placeholder stays — and it is 476 bytes of POSIX shell script carried
under an .exe name, because that is the package's declared bin on every
platform. npm still exits 0, because the download it skipped was optional.

Windows then hands that text file to the PE loader, which refuses a file with no
PE header and reports it through cmd.exe as "not compatible with the version of
Windows you're running". The message names neither npm nor a postinstall, so it
reads as a wrong-architecture or unsupported-OS problem and sends people off to
audit their Windows build, where they find nothing wrong.

installAndVerify already recovers this exact class of failure for
claude-code (postinstall + reinstall) and for codex on Windows. It had
nothing for codev-code.

The fix

• recoverCodevNativeBinary, mirroring the Claude Code recovery: re-run the
  package's own postinstall.mjs, re-verify, then force a reinstall and
  re-verify. Verified end-to-end against a genuinely broken install —
  476-byte placeholder → 176 MB binary → --version answers 1.18.4-8.
• The recovery reinstall carries --force. npm re-runs install scripts only
  when it considers the tree changed, so once the placeholder is in place a plain
  npm i -g codev-code can report success without ever touching it. Without
  --force the recovery would be a no-op on exactly the machines that need it.
  Stage 1 sidesteps npm entirely for the same reason.
• Report the placeholder, not the loader error — but only where the size
  probe positively confirms the stub. A full-size binary that still won't run is
  a genuine incompatibility and keeps its own message; rewriting that would be
  the same mistake in reverse.
• Matching launch-time hint in runAgent, alongside the existing Claude one.

Second bug, visible in the same report

That Starting CoDev Code... in the middle of the error is ours. verifyInstall
ran the bare CLI name through PATH, so on a machine that had installed before,
codev resolved to CoDev's own ~/.codev-hub/bin/codev.cmd, which re-execs
codevhub codev --version → runAgent. Verification was measuring our shim
rather than the binary npm had just written, and spawning a second hub process to
do it. It now strips the shim dir from the child's PATH, exactly as run.ts
already does when it launches an agent for real.

Tests

10 new tests in tests/lib/npm.test.ts. Each was mutation-checked against the
production change it covers — removing the recovery wiring fails 4, removing
--force fails 1, removing the shim strip fails 1.

Full suite: 1424 passed, 2 skipped. pnpm fix, pnpm typecheck, pnpm build
and the bundled node dist/index.js --version smoke run all pass.

Follow-up, not in this PR

Recovery makes the common case succeed, but if it fails the wizard still parks on
install-failed with no way forward, because the locked flagship agent is the
whole survivor set. Whether a locked tool should be able to strand the flow is a
design question worth taking separately.

🤖 Generated with Claude Code