Keep worktrees git could not read, never delete them

Any git error on a directory under the worktree root was classified orphan,
and orphan deletes the directory outright, so a transient failure reading the
source root became data loss on a plain `agentws prune --yes`.

- prove a backing repo gone by stat before calling a directory an orphan
- classify an unexplained git failure as keep, naming the error
- refuse to remove a worktree whose git state is unknown, even with --include-keep
- spell out that --include-keep discards uncommitted and in-progress work

README.md

@@ -181,11 +181,18 @@ spelled out, or `--json` for scripting. Neither form needs a terminal.
 | `--no-fetch` | judge against the refs already on disk, for offline use |
 | `--json` | emit the report as JSON on stdout, notes on stderr |
 | `--include-unmanaged` | also remove worktrees outside the worktree root |
-| `--include-keep` | dangerous: also remove worktrees classified `keep`, never their branch |
+| `--include-keep` | dangerous: also remove worktrees classified `keep`, destroying uncommitted and in-progress work |
 
 Without `--include-unmanaged` a hand-made worktree is reported and then skipped,
 naming the flag that would remove it. `--include-keep` is the only way past a
-`keep`, and it still leaves the branch, so the commits outlive the worktree.
+`keep`. It leaves the branch, so committed work outlives the worktree, but
+`git worktree remove --force` discards a dirty working tree and a paused
+rebase's sequencer state without a word, and no branch was carrying those.
+
+A directory under the worktree root is deleted outright only when its git dir
+and the repo's shared `.git` are both proven absent by `stat`. When git merely
+fails to answer for a checkout, the verdict is `keep` with the error as its
+reason: an unread state is never a dead one.
 
 ### Auth / credential-helper design