[Feature] `git worktree` integration

Start by reviewing the current wt commands and the referenced WIP PR, then compare their behavior with git worktree add and git worktree list. Trace how worktrees, IntelliJ files, contexts, and configs are currently managed. Done means an agreed scope and design for adopt, listing external worktrees, switching between them, and non-interactive operation.

Motivation

With AI coding agents & tooling increasingly adopt worktree workflows (most recently, Claude Code natively supporting via claude --worktree), being able to hook into the standard worktree flows would be ideal.

Proposed Changes

New adopt flow

• Take any existing worktree and give it the wt treatment.
• Mark it as adopted (e.g. w/ a marker file .git/wt/touch)

The core wt commands becomes a mostly a porcelain for common operations:

• wt add -> git worktree add ... then wt adopt
• wt list -> git worktree list w/ niceties. It should list all worktrees, adopted or no, and maybe decorate the adopted ones (worktrees with the marker file)
• wt switch -> git worktree list to pick from all worktrees, adopt the selection if it hasn't been adopted yet, then do the symlink switch.

Work trees does not have to be in the tool-managed worktree base directory for it to be adopted. The base directory should still be there for wt add flow.

Manage IntelliJ files, context & configs only

Allowing wt to adopt other worktrees managed by other tools (e.g. ~/conductor/workspaces/...) means it should rely less on the repos and their worktrees to be under ~/.wt.

It seems to me that as long as we can discover w/c root repos are managed & w/ subtrees are adopted by wt, then they don't have to live in ~/.wt/.... It can remain as the home for the IntelliJ files, and contexts w/ their configs; things that only wt needs to touch.

Not necessary, but we can also follow the XDG Base Directory Spec:

# $XDG_DATA_HOME for user-specific application-data that users don't need to deal with:
~/.local/share/wt/intellij-files/<CONTEXT>/...

# $XDG_CONFIG_HOME for user-specific, application configuration that users may need to deal with:
~/.config/wt/contexts/<CONTEXT>/...

Ensure core operations work 100% non-interactive

This is probably already the case, but they need to be non-interactive-first by design so they can used with zero issues in any orchestration.

Examples:

• A repository can have a post-checkout hook that detects a worktree checkout and auto-adopt.
• Conductor post-checkout script
• etc.

Working on a PoC on this based on the WIP PR I have open, but would love your thoughts before I get too deep 😄