#18961: fix: detect pnpm package manager in openclaw update

## Problem When running `openclaw update` on a pnpm global installation, it fails with: > Skipped: this OpenClaw install isn't a git checkout, and the package manager couldn't be detected. ## Root Cause pnpm uses a content-addressable store (`.pnpm/` directory) where packages are stored with their hash, and symlinks are created in `node_modules/`. The `detectGlobalInstallManagerForRoot` function only checked if the resolved package path directly matches `{globalRoot}/openclaw`, but with pnpm: - `pnpm root -g` returns: `/home/user/.local/share/pnpm/global/5/node_modules` - Actual package is at: `/home/user/.local/share/pnpm/global/5/.pnpm/openclaw@.../node_modules/openclaw` - The symlink `{globalRoot}/openclaw` points to the actual location ## Solution Also check if the expected path is a symlink that resolves to the actual package path. ## Testing - [x] Tested locally with pnpm global installation - [x] `openclaw update` now correctly detects pnpm instead of showing "Skipped" error ## AI-Assisted This fix was identified and implemented with AI assistance (Claude). The code was reviewed and tested manually. <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixes pnpm global installation detection in the `openclaw update` command. pnpm uses a content-addressable store (`.pnpm/` directory) with symlinks in `node_modules/`, so the resolved package path doesn't directly match the global root + package name. The fix adds a symlink target resolution check after the existing direct path comparison. - Adds `tryRealpath(expected)` call to resolve the symlink at `{globalRoot}/openclaw` before comparing with the actual package path - Change is narrowly scoped to the pnpm detection path in `detectGlobalInstallManagerForRoot` - No test coverage added for this specific symlink scenario (existing test file `update-runner.test.ts` does not cover `detectGlobalInstallManagerForRoot` directly) <h3>Confidence Score: 4/5</h3> - This PR is safe to merge — it adds a fallback symlink check that only activates when the existing direct-path match fails. - The change is minimal, well-scoped, and correct. It adds a secondary symlink resolution check that won't affect existing npm/bun detection paths. The only minor concern is the lack of a unit test for this specific scenario, but the logic is straightforward and the author confirmed manual testing. - No files require special attention. _{Last reviewed commit: 5d66e06} <!-- greptile_other_comments_section --> _{(4/5) You can add custom instructions or style guidelines for the agent [here](https://app.greptile.com/review/github)!} <!-- /greptile_comment -->