gstack-update-check --apply reports UPGRADE_AVAILABLE but doesn't perform the pull

## Summary

`~/.claude/skills/gstack/bin/gstack-update-check --apply` exits 0 and emits `UPGRADE_AVAILABLE `, but the working tree is unchanged. `VERSION` still reads the old version. Subsequent runs produce identical output until a manual `git pull` is performed. The `--apply` flag appears to fall through to the report-only path.

## Reproduction

```bash
# Install gstack at an older commit, e.g. 1.26.4.0
$ cat ~/.claude/skills/gstack/VERSION
1.26.4.0

# Run with --apply
$ ~/.claude/skills/gstack/bin/gstack-update-check --apply
UPGRADE_AVAILABLE 1.26.4.0 1.26.5.0

# Check state — unchanged
$ cat ~/.claude/skills/gstack/VERSION
1.26.4.0

# Manual workaround pulls successfully
$ cd ~/.claude/skills/gstack && git pull origin main
Updating 19e699ab..c7aefc1a
Fast-forward
CHANGELOG.md | 41 +++++++++++
...
$ cat ~/.claude/skills/gstack/VERSION
1.26.5.0
```

## Expected vs actual

| | Expected | Actual |
|---|---|---|
| Output with `--apply` | `UPGRADED 1.26.4.0 -> 1.26.5.0` (or similar success message) | `UPGRADE_AVAILABLE 1.26.4.0 1.26.5.0` (identical to no-flag path) |
| Working tree | Updated to `c7aefc1a` | Still at `19e699ab` |
| VERSION file | `1.26.5.0` | `1.26.4.0` |
| Exit code | 0 with state mutation | 0 with no state mutation |

The output with `--apply` is identical to the report-only output, suggesting the apply branch isn't being taken — or is being taken but silently no-op'ing.

## Environment

- macOS Sequoia 15.x
- Bash on Apple Silicon
- gstack `1.26.4.0` -> target `1.26.5.0`
- gstack repo HEAD before workaround: `19e699ab`
- gstack repo HEAD after manual `git pull`: `c7aefc1a`
- Working tree clean (no uncommitted changes, no untracked files in `~/.claude/skills/gstack`)

## Suggested investigation paths

1. Is the `--apply` branch in `gstack-update-check` invoking `git pull` (or equivalent)? If so, is its exit code captured and surfaced?
2. If `git pull` is invoked, what's its actual stdout/stderr? Could it be silently failing on a precondition (detached HEAD check, branch tracking, network) and falling through to the report message?
3. The fact that the output exactly matches the no-flag path is the strongest hint — suggests `--apply` either isn't being parsed, or is parsed but the apply codepath unconditionally emits the same `UPGRADE_AVAILABLE` line before bailing.

## Workaround (for users hitting this)

```bash
cd ~/.claude/skills/gstack && git pull origin main
```

## Why it matters

gstack's value compounds on every session using the latest version — newer releases ship bug fixes and specialist capabilities that prevent CI failures downstream. A silent no-op on `--apply` means projects falsely believe they're current. It's also the same trigger-vs-outcome failure pattern that several gstack skills (`/review`, `/qa` infra-class checks) help catch in user code, so worth fixing in the tool that enforces the discipline.

Happy to provide additional traces or test patches if useful. Thanks for the great work on gstack — it's load-bearing in our delivery pipeline.