fix: /ship Steps 7-8 not idempotent — re-run after partial failure corrupts VERSION and CHANGELOG

## Problem

`/ship` executes a multi-step sequence: version bump → changelog → commit → push → PR create. If Step 7 (`git push`) succeeds but Step 8 (`gh pr create`) fails (GitHub API outage, auth token expiry, rate limiting), re-running `/ship` corrupts state:

- **VERSION gets double-bumped** (e.g., 0.13.5 → 0.13.6 on first run, then 0.13.6 → 0.13.7 on re-run)
- **CHANGELOG gets duplicate entries** (same changes listed under two versions)
- No way to safely resume from where it left off

The dangerous window is narrow (one step) but the blast radius is real — manual cleanup is required.

## Why this matters

`/land-and-deploy` already handles partial failure well (Step 6 offers revert, Step 8 has full revert procedure with branch protection awareness). `/ship` doesn't apply the same rigor despite being the more frequently used skill.

## Suggested fix

Make the critical section idempotent rather than building a rollback framework:

1. **Before push:** check if branch is already pushed (`git rev-parse @{u}` or `git ls-remote`)
2. **Before PR create:** check if a PR already exists for the branch (`gh pr list --head `)
3. **Before version bump:** check if VERSION was already bumped in a prior run (compare against base branch)

This is ~10 lines of shell, not a new subsystem.

## Reproduction

```bash
# 1. Run /ship on a feature branch
# 2. Simulate gh failure: revoke token or disconnect network after push
# 3. Re-run /ship
# 4. Observe: VERSION bumped again, CHANGELOG has duplicate section
```

## Context

- `/land-and-deploy` already handles this pattern (Steps 6, 7, 8 all have failure recovery)
- Issue #341 covers cross-session resume but not within-session partial failure
- The agent IS the resume mechanism — but it can't safely resume if the steps aren't idempotent