autoupdate: Cursor IDE's detached spawn doesn't complete `npm install -g`

## Summary

After PR #97 (`feat/centralize-autoupdate`), the autoupdate centralization works for 4 of 6 agents end-to-end (claude-code, codex, hermes, pi). **Cursor** is one of the two with a follow-up: the trigger fires correctly, but the detached `hivemind update` spawned from inside Cursor IDE never completes the upgrade.

## Symptom

When Cursor's `sessionStart` hook fires inside the IDE (real agent chat started in a Cursor workspace):

- ✅ `~/.deeplake/hook-debug.log` shows `[autoupdate] agent=cursor entered` + `dispatched`
- ✅ `~/.deeplake/.autoupdate-last-check` cache file mtime is touched (proves the helper ran)
- ❌ Global hivemind binary stays at the pre-test version (e.g. 0.6.99)
- ❌ `~/.cursor/hivemind/.hivemind_version` doesn't move

The spawned `hivemind update` either silently failed or its `npm install -g` had no effect.

## Confirmation that the upgrade chain itself is fine

`hivemind update` invoked from a normal terminal (with the same verdaccio routing in `~/.npmrc`) upgrades global 0.6.99 → 0.7.99 in ~10 seconds. So the chain is correct; only the Cursor-IDE-spawned invocation fails.

## Likely root causes

1. **Snap sandbox env**. Cursor at `/snap/bin/cursor` runs with restricted filesystem and child-process environment. The detached child may not have access to:
- `~/.npmrc` (which carries the user's npm registry routing)
- `/usr/local/bin/npm` or the nvm-managed `npm` (PATH inheritance may be empty or restricted in snap)
2. **`stdio: \"ignore\"`** in `defaultSpawn` discards stdout/stderr, so any error from `npm install -g` is invisible. We get no breadcrumb to diagnose.
3. **Cursor IDE may kill its own child processes** on workspace close. `child.unref()` only detaches from the event loop; it doesn't immunize the child against `SIGHUP` from a closing parent on some platforms (process group inheritance).

## Suggested fix

1. Capture spawn output to a rotating log under `~/.deeplake/.autoupdate-out/.log` (keep last 10) so future failures are diagnosable.
2. Set `process.env.PATH` explicitly on the spawn so the child can find `npm` regardless of whether the parent had it.
3. Use `setsid` (Linux) / new process group on Linux so `SIGHUP` from Cursor doesn't kill the child.
4. Verify against `cursor` snap on at least one fresh install.

## What this PR established for Cursor

- Cursor's session-start hook calls `autoUpdate(creds, { agent: \"cursor\" })`
- Trigger fires (cache-file mtime confirmed in real Cursor session)
- Direct helper invocation via synthetic stdin produces the expected `[autoupdate] agent=cursor entered` log line
- The detached `hivemind update` spawned from inside Cursor IDE doesn't complete its npm install (env/sandbox-specific)

## Priority

Low. The trigger fires correctly — Cursor users on cloud-deployed npm versions are still served by other agents' triggers (e.g. opening codex on the same machine triggers the upgrade, which refreshes Cursor's bundle too). And manual `hivemind update` from a terminal works fine.

Track separately from PR #97 (centralization itself is verified for 4/6 agents and source-confirmed for the other 2).