v1.82.1

## [1.82.1] - 2026-05-16

### Fixed — P0: force-update no longer overwrites user projects (#51, #52)

`executeForceUpdate` previously used `getRepoRoot()` to decide which
directory to update. `getRepoRoot()` preferentially returns the user's
surrounding git project — correct for evolution signals, **catastrophic**
for "delete everything except .git/node_modules/memory/MEMORY.md and copy
the evolver tarball on top of it." When the Hub pushed a `force_update`
directive (via heartbeat or event poll) to a node whose process.cwd() was
inside any other git repository, the deletion loop ran inside that repo
and the user lost their files.

This was reproducible end-to-end via `cd /tmp/anything-with-.git;
trigger executeForceUpdate` — the user's files were replaced with the
evolver package contents and the user's `package.json` was rewritten to
`@evomap/evolver`. We confirmed the bug actually triggered against
`evolver-private-dev` itself during fix development (recovered via
`git reset --hard HEAD`) — that's the strongest possible evidence for
the severity.

The fix introduces a new `paths.getEvolverInstallRoot()` that returns
the evolver package directory (`path.resolve(__dirname, '..', '..')`)
regardless of `process.cwd()` or `EVOLVER_REPO_ROOT`. `forceUpdate.js`
now uses this `INSTALL_ROOT` for every read, delete, and copy. A
defense-in-depth guard refuses the update entirely if
`INSTALL_ROOT/package.json` does not name `@evomap/evolver` — so any
future path-resolution regression fails closed instead of wiping an
unrelated directory. The staging tmp directory also moves to
`os.tmpdir()` because `INSTALL_ROOT`'s parent is typically not writable
under a global npm install.

**Recommended action**: upgrade immediately. Anyone running
`evolver --loop` from inside any git repository is at risk under
v1.82.0 and earlier.

Credit: issue reported by **cloudcarver**, codex POC reproducer
diagnosed by **cloudcarver**, fix landed in #52.