ExitWorktree falsely warns about unmerged commits after squash merge

Bug

After a PR is squash-merged to main, ExitWorktree with action: "remove" refuses to remove the worktree:

Worktree has 1 commit on worktree-655-add-pd-execute-command. 
Removing will discard this work permanently.
Confirm with the user, then re-invoke with discard_changes: true

Root Cause

ExitWorktree checks if the worktree branch has commits not on the original branch using SHA comparison (e.g., git log main..worktree-branch). After a squash merge, main has a new commit SHA with the same content — the worktree's original commit SHA is technically not on main, so the tool thinks the work hasn't been merged.

Expected Behavior

After a squash merge, ExitWorktree should recognize that the work has been merged and allow removal without requiring discard_changes: true.

Suggested Fix

Instead of (or in addition to) raw SHA comparison, ExitWorktree could:

• Use git cherry main worktree-branch to check if commits have equivalent changes already on main (empty cherry = merged)
• Or check if the branch has an associated merged PR via gh pr list --head <branch> --state merged

Reproduction

1. EnterWorktree with name test-branch
2. Make changes, commit, push
3. Create PR and squash merge: gh pr merge --squash
4. ExitWorktree with action: "remove" → refuses, warns about unmerged commits
5. Must re-invoke with discard_changes: true to proceed

Workaround

Always pass discard_changes: true after independently confirming the PR is merged. This works but adds friction to every worktree workflow.

Environment

• Claude Code CLI (latest)
• Git worktrees via EnterWorktree / ExitWorktree
• Squash merge via gh pr merge --squash