Add native jj support

[OverHash]

dmux is currently tightly coupled to using git for worktrees. This works great, but it doesn't work nicely when using the jj vcs instead!

Adding native jj support (e.g., through a config set at the project or system level for what VCS to use) would benefit jj users who also use dmux.

To add better jj support, there needs to be a few changes:

UI Changes

• Pane creation needs to handle jj workspace creation instead
  • New pane flow creates a git worktree currently, auto-generates branch names, and on failure prints Failed to create worktree and git worktree prune && git branch -D ...
  • Reopen popup filters by Worktrees / Local / Remote
  • placeholder Search branches and empty states like No local branches or worktrees. Enable remote to scan
  • In general, branch searching and handling might need to also handle bookmarks in a jj backend
  • “Merge worktree to main branch”, “Copy worktree path to clipboard”, “Open worktree in external editor”, “Create Child Worktree”, “Add Terminal to Worktree”, “Add Agent to Worktree” in pane actions all need handling

The entire merge flow has quite a few things

• “Merge Worktree”, Merge "" into ?, “Merge worktree into main”, “Failed to merge X into worktree”, “Failed to merge into main”, “Merge Main -> Worktree / Worktree -> Main”

which makes me question if jj merge support is even worth adding to begin with? I am tempted to say no 😛

I'm also not sure if dmux would need to have some local state tracking the vcs backend that is associated with a pane. It might be helpful. There's src/utils/worktreeMetadata.ts of note which we could hook into or adapt.

• Updating docs to reference jj support (rather than just general git repositories)
  • Shortcuts popup/docs repeat “Create child worktree”, “Reopen closed worktree”, “Add agent to worktree”
  • “Keep worktree and branch”, “Close and remove worktree”, “Remove worktree and delete branch”, “This worktree is still in use...”
  • Renaming also needs to have a think about the UX changes. I note that renaming is currently disabled really.
  • User-facing comparator labels mention “target branch” and “working tree base”; docs say sort by “git status” in:

There's also some things like like hook names and env are worktree/branch-specific: worktree_created, before_worktree_remove, DMUX_WORKTREE_PATH, DMUX_BRANCH. I'm not sure if "worktrees" is the best name to have still. It might still be fine to keep the term worktrees, for backwards compatibility!

Backend changes

• src/types.ts has lots of pane/state model that is git branch-centric (branchName, worktreePath, mergeTargetChain)
• src/utils/git.ts is the current core Git handling/helpers. It handles current branch, default branch, branch existence, dirty/conflict checks, orphaned worktree discovery, but no everything that dmux uses.
  • src/utils/worktreeDiscovery.ts, src/services/WorktreeCleanupService.ts, and src/services/WorktreeCleanupService.ts is also of use.
• src/utils/projectRoot.ts currently does startup/project detection, and assumes git roots/worktrees, and even git init. I'm OK with us assuming that git is installed and jj support only on existing-initialized jj repositories.
• src/utils/paneCreation.ts, which currently handles baseBranch/branchPrefix, runs git worktree prune/add, so needs to handle whatever generic/jj VCS would do.
• src/utils/reopenWorktree.ts handles reopens an existing workspace/pane and reconstructs pane state from stored metadata plus current branch
• src/utils/resumeBranches.ts has lots of branch-centric logic right now
• src/utils/mergeValidation.ts, src/utils/mergeExecution.ts, src/utils/mergeTargets.ts, src/actions/implementations/mergeAction.ts, and src/actions/merge/mergeExecution.ts does lots of git work as well. I propose that merge functionality isn't supported in jj to begin with (I don't use dmux's merge, so If I'm implementing, I'm not in need of it yet!)
• src/actions/implementations/closeAction.ts of closing panes needs to handle cleanup correctly
• src/utils/conflictResolutionPane.ts and src/utils/conflictMonitor.ts depend on git merge state right now (MERGE_HEAD)