feat(tools/jujutsu): Jujutsu (jj) support for the local dev-loop

Add `tools/jujutsu/` so the local dev-loop skills can run on **Jujutsu (`jj`)** working copies. `jj` is Git-compatible at the storage layer but exposes a **fundamentally different working model** — no staging area, anonymous/auto-evolving changes, first-class conflict commits, and `jj`-style revsets instead of branches. The fix-workflow and code-review skills, which assume Git's branch/commit/`git add` model, would produce wrong or confusing steps on a `jj` repo even though the backing store is Git.

**Capabilities to provide:**

- Map the dev-loop primitives onto `jj`: `jj new`/`jj describe` for commit, `jj diff`, `jj log`, `jj bookmark` for branch-equivalent hand-off
- Translate the fix-workflow "create branch → commit → push" recipe into the `jj` change/bookmark model
- Detect a `jj` working copy and route through this shim instead of raw `git`
- Reuse the VCS-capability abstraction from `tools/mercurial/`

**Why:** `jj` adoption is growing fast among individual maintainers and at **Google** (its primary sponsor), and it's a common front-end over Git-hosted repos (GitHub/GitLab). Because it's Git-backed, an adopter can use `jj` locally while the forge stays GitHub — so this is low-risk, high-leverage support that several power-user maintainers would benefit from immediately.

**Reference:**

- Jujutsu: https://github.com/jj-vcs/jj
- Tutorial / mental model: https://jj-vcs.github.io/jj/latest/tutorial/
- Depends on the VCS abstraction from the Mercurial bridge issue

Start by reading the VCS-capability abstraction in tools/mercurial/ and the fix-workflow and code-review skills that currently assume Git. Add the tools/jujutsu/ shim so jj working copies are detected and routed through jj equivalents for commits, diffs, logs, and bookmark hand-off; done means those workflows no longer emit Git-specific steps for jj repositories.

Written by the indexing model from the issue text.