docs: caveat worktrees.md sandbox-allowlist claim, add wt orphan-branch note

claude/rules/worktrees.md

@@ -8,5 +8,6 @@ When a repo has `wt` on `PATH` (worktrunk is installed globally via [dotfiles](~
 
 - Create: `wt switch --create <name> --yes --no-cd --format=json` (optionally `--base <ref>`). Parse `.path` from the JSON result and `cd` there explicitly, or pass `-C <path>` to subsequent `wt`/git calls -- don't rely on `wt`'s shell-integration `cd` (that's a shell function from `wt config shell install`; a Bash tool call invokes the raw binary, which doesn't cd the calling shell on its own).
 - Remove when done: `wt remove <name> -y` (deletes the worktree and, if merged, the branch). Unlike `EnterWorktree`/`ExitWorktree`, there's no automatic keep/remove prompt at session end -- clean up explicitly, or leave it if the user wants to keep working there.
-- **These commands work under the command sandbox without any extra allowlist entry.** `<repo>/.claude/worktrees/<branch>` is a subpath of the repo you started the session in, so it falls under the sandbox's implicit cwd allowance -- `wt switch --create`, relative-path writes after you `cd` in, `git add`, and build artifacts (`node_modules/.tmp`, `dist/`, `.pytest_cache`) all succeed. (This is why the layout moved off `~/worktrees`: that path was a sibling of `~/github.com`, outside any session's cwd tree, so it needed its own `allowWrite` entry in `claude/roles/base.jsonc` -- nested worktrees don't.) An `Operation not permitted` here is now a real failure worth investigating, not something to paper over with `dangerouslyDisableSandbox`. The one genuine exception is still `git push`/`fetch` over SSH, which is a network-policy deny on port 22 -- see the repo's CLAUDE.md.
+- **These commands work under the command sandbox without any extra allowlist entry -- for the cwd-allowance mechanism this layout was designed to satisfy.** `<repo>/.claude/worktrees/<branch>` is a subpath of the repo you started the session in, so it falls under the sandbox's implicit cwd allowance -- `wt switch --create`, relative-path writes after you `cd` in, `git add`, and build artifacts (`node_modules/.tmp`, `dist/`, `.pytest_cache`) all succeed. (This is why the layout moved off `~/worktrees`: that path was a sibling of `~/github.com`, outside any session's cwd tree, so it needed its own `allowWrite` entry in `claude/roles/base.jsonc` -- nested worktrees don't.) An `Operation not permitted` here is now a real failure worth investigating -- but check first whether it's a _separate_ sandbox mechanism: a hardcoded path/basename denylist (`.claude/agents/*`, `.claude/commands/*`, `.mcp.json`, `.git/hooks/*`, dotfile rc files) that applies regardless of cwd and bites any repo that ships those paths. (Some repos maintain their own reference docs or triage skills for this specific denylist -- check for one before reaching for `dangerouslyDisableSandbox` by reflex.) The one other genuine exception is still `git push`/`fetch` over SSH, which is a network-policy deny on port 22 -- see the repo's CLAUDE.md.
+- **If a sandboxed `wt switch --create` fails on that denylist, a same-named retry with `--create` can then fail with "Branch already exists".** That's expected fallout from the branch having been created before the first attempt's `git worktree add` failed partway through, not a real conflict. Follow `wt`'s own suggested command (`wt switch <name>`, no `--create`) unsandboxed; it does a fresh checkout and succeeds.
 - Fall back to `EnterWorktree` only when `wt` isn't installed, or outside a git repo (worktrunk requires one; `EnterWorktree` delegates to `WorktreeCreate`/`WorktreeRemove` hooks in that case).