[Bug] Automatic update fails silently or becomes ineffective due to PATH shadowing and non-standard NPM prefixes

## Description

The automatic update feature in `gemini-cli` can result in a state where the update is reported as successful (or fails silently/inaccurately) but the user continues to run the old version. This occurs on systems where multiple global installation paths exist (e.g., `/usr/local/bin` and `/usr/bin`), common in Linux/WSL environments or when switching between `npm` and `pnpm` global configurations.

## Type

Bug

## Context/Background

- **OS:** Linux (Ubuntu/WSL)
- **Installation Method:** `npm install -g @google/gemini-cli`
- **Behavior:** The CLI detected an update from v0.31.0 to v0.32.1. The auto-update triggered `npm install -g`, which installed the new version to `/usr/bin/gemini` (the current `npm config get prefix`). However, the active binary being executed was `/usr/local/bin/gemini`, which was not updated. The user was left running v0.31.0 despite the successful update notification.

## Investigation Findings

### Affected Code

- **File**: `src/utils/installationInfo.ts` (and its compiled JS counterpart `dist/src/utils/installationInfo.js`)
- **Reason**: The `getInstallationInfo` function determines the `updateCommand` based on string matching against `process.argv[1]` (the path to the current binary). It assumes that running the generated `updateCommand` (e.g., `npm install -g @google/gemini-cli@latest`) will update the *specific* binary that is currently running.

- **File**: `src/utils/handleAutoUpdate.ts` (and `dist/src/utils/handleAutoUpdate.js`)
- **Reason**: The `handleAutoUpdate` function executes the update command in a detached process and reports success based on the exit code of that command, without verifying if the binary that triggered the update was actually replaced or if it remains the primary binary in the user's `PATH`.

### Root Cause/Analysis

The current implementation lacks a verification step to ensure the `npm` (or other package manager) "global" prefix aligns with the directory containing the currently executing `gemini` binary. If a user has a legacy installation in `/usr/local/bin` that precedes the NPM prefix in their `$PATH`, the global update will target the wrong location, leading to persistent "stale" versions.

---

**Note**: This issue was generated using the `github-issue-creator` skill.