feat(jj): add experimental jj support

[SecretAardvark]

This PR adds experimental Jujutsu (jj) support to Sidecar.

When the jj_plugin feature flag is enabled, Sidecar detects jj workspaces and can automatically use the new jj status plugin instead of the
git plugin. This behavior can be configured via plugins.vcs.preferred to prefer auto, jj, or git.

Includes

• introduces internal/vcs/jj
• adds jjstatus plugin
• adds config: plugins.vcs.preferred
• gates the feature behind jj_plugin

Behavior

• auto (default): prefer jj when inside a jj workspace
• jj: prefer jj when available
• git: always use the git plugin

Notes

• Git behavior remains unchanged for non-jj repositories
• jj support is intentionally gated behind a feature flag for incremental rollout

[marcus]

Thanks for putting real work into this. The structure is clean, it's flag-gated, and the tests are there. I'm going to close it, and I want to be straight about why rather than leave it sitting open.

Sidecar's git surface is about 21k lines across ~70 files: staging, discard, stash and stash-pop, branch picker, push and pull menus with merge strategies, remotes, GitHub integration, history with search, minimap, syntax highlighting, diff paging, a filesystem watcher. The jj plugin here covers status, log graph, diff, open, and edit. That's a reasonable first slice, but merging it commits the project to closing that gap and then keeping two VCS surfaces in step forever, and every future git feature becomes a two-surface decision.

I don't use jj and don't plan to, so I'd be maintaining and reviewing that second surface without ever exercising it. That's the part I can't take on. If someone wanted to come on as an ongoing jj maintainer, owning the parity gap, the review load, and the bug reports, I'd reconsider, and I'd say the same to you if that's something you'd want. It's possible Sidecar supports jj at some point, just not right now.

Sorry to send you away with a no after this much work. I appreciate you asking with code rather than an issue.