[Feature] `git worktree` integration

## 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](https://specifications.freedesktop.org/basedir/latest/):

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

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

### 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 😄