local-install: silent no-op when reinstalling same version

[waleedkadous]

Problem

`scripts/local-install.sh` does:

```sh
npm uninstall -g @cluesmith/codev @cluesmith/codev-core 2>/dev/null || true
npm install -g
```

When the previously-installed version equals the tarball version, the install reports success but the on-disk `@cluesmith/codev` directory ends up with stale files in some cases. Reproduced during v3.0.0-rc.12 testing on 2026-04-25:

1. First `pnpm -w run local-install`: script printed `Installed: 3.0.0-rc.12`, but `codev --version` immediately afterward returned `3.0.0-rc.11`.
2. `/opt/homebrew/lib/node_modules/@cluesmith/codev/dashboard-dist/assets/` retained Apr-18 timestamps from a previous install — the new tarball's contents had not landed.
3. Manually running `npm uninstall -g` then `npm install -g ` resolved it.

Possible root causes:

• `npm install -g` over a same-version tree may skip file extraction.
• `npm uninstall` followed immediately by `npm install` may hit a race where npm's lock or tracker file confuses the second invocation.
• pnpm pack may have produced a tarball whose contents differ from the previous one despite the same version string, and npm's same-version short-circuit ignored the diff.

Fix

Make the uninstall+install fully clean:

```sh
GLOBAL_ROOT="$(npm root -g)"
npm uninstall -g @cluesmith/codev @cluesmith/codev-core 2>/dev/null || true
rm -rf "$GLOBAL_ROOT/@cluesmith/codev" "$GLOBAL_ROOT/@cluesmith/codev-core"
npm install -g "$REPO_ROOT/packages/core/cluesmith-codev-core-".tgz "$REPO_ROOT/packages/codev/cluesmith-codev-".tgz
```

The `rm -rf` between uninstall and install guarantees no stale files survive when versions match.

Optionally: after install, verify file content (e.g. compare a checksum of `dashboard-dist/assets/index-*.js` between tarball and installed copy) and fail loudly if they differ.

Acceptance

• Running `pnpm -w run local-install` twice in a row, with the second run packing a different bundle but the same version, results in the new bundle being on disk.
• `codev --version` immediately after the script reports the same version every time the script does.

[waleedkadous]

Real root cause (and proper fix)

The original `rm -rf` fix was insufficient — the bug only manifests when invoking via `pnpm -w run local-install` (the documented entry point), not when running `bash scripts/local-install.sh` directly. That's why my earlier test passed.

Root cause: `pnpm run` injects `npm_config_prefix=` into the script's environment. This redirects `npm install -g ` to install into `/lib/node_modules/@cluesmith/` instead of the system-global location (`/opt/homebrew/lib/node_modules`). The script then reports "Installed: 3.0.0-rcX" because `codev --version` resolves the workspace-local install (which IS on PATH inside the pnpm-run script context). After pnpm exits, PATH reverts and the user's real global binary (still on the previous version) is what runs.

This is also why `pnpm -w exec scripts/local-install.sh` worked but `pnpm -w run local-install` did not — `exec` doesn't apply the prefix override that `run` does.

Reproduce:
```sh
pnpm -w run local-install # reports "Installed: NEW", but /opt/homebrew unchanged
ls /Users/mwk/Development/cluesmith/codev/lib/node_modules/@cluesmith/ # the rogue install is here
```

Fix: `unset npm_config_prefix` (and `PNPM_CONFIG_PREFIX`) at the top of `scripts/local-install.sh`. Verified end-to-end:

• Pre-fix: install lands in workspace `lib/`, system `afx --version` stays stale.
• Post-fix: install lands in `/opt/homebrew/lib/node_modules`, system `afx --version` reports the new version.

Reopening to track the actual fix.