Worktree Isolation

Ensure the current work happens in an isolated workspace, without disturbing the user's main checkout. Most coding harnesses now create a worktree by default at session start, so the common case is that isolation already exists.

Done when: the caller is working in an isolated tree — existing or newly created — and its path and branch have been reported, or a blocker has been reported instead.

Order of operations: detect existing isolation -> prefer a native worktree tool -> fall back to plain git. Never create a worktree the harness cannot see.

Two modes, set by the caller's need:

• New work (default). No ref named — create a fresh branch from a base (trunk). This is what ce-work and ce-code-review use when the user picks the worktree option.
• Isolate an existing ref. The caller names a PR head, branch, or commit — attach the worktree to that ref instead of creating a new branch. A branch can be checked out in only one worktree at a time. If the named ref is already checked out anywhere (most commonly as the primary checkout's current branch), do not create a second worktree — report that it is already checked out at <path> and let the caller act (work there in place; or, only if a clean separate tree is essential, create a detached worktree at the same commit).

Step 0: Detect existing isolation

Compare the resolved absolute git dir against the resolved absolute common git dir. Git mixes absolute and relative forms depending on the current directory (from a subdirectory of a normal checkout, --git-dir comes back absolute while --git-common-dir may be relative), so a raw string compare yields a false "already isolated":