ExitWorktree(remove) reports 'Discarded N commits' even when commits are already merged elsewhere

Environment: Claude Code 2.1.191, Linux (WSL2)

Steps to reproduce:

1. EnterWorktree(name: "foo") — creates worktree + branch worktree-foo.
2. Make several commits on worktree-foo via normal work.
3. From the main checkout, fast-forward merge: git merge worktree-foo (succeeds, main now contains all those commits).
4. ExitWorktree(action: "remove", discard_changes: true).

Observed: Tool reports "Discarded N commits" and removes both the worktree directory and the worktree-foo branch.

Expected: The message should distinguish "these commits are unreachable from any other ref and will be lost" from "these commits are also reachable from <other-branch> and are safe" — e.g. by checking git merge-base --is-ancestor <branch> <other-refs> before choosing the wording. As written, the message is indistinguishable from genuine data loss, which is alarming and forces the user (or the calling agent) to manually verify safety every time, even in the most common case (worktree finished → merged → cleaned up).

Secondary effect: Because removal also deletes the branch, any skill/runbook that does ExitWorktree(remove) followed by a manual git branch -d <branch> step (e.g. superpowers' finishing-a-development-branch skill) will always hit "branch not found" on that second step, since the tool already removed it.