Route isolated checkouts to jj workspaces

bash-guard mapped 20 mutating git verbs to their jj equivalents but not
`worktree`, so `git worktree add` passed the hook untouched. Claude Code's
built-in EnterWorktree/ExitWorktree tools were a second hole: they create a
git worktree directly, never going through Bash, so the guard never saw them.

A git worktree in a jj repo is not a jj workspace. jj does not manage it, it
never appears in `jj workspace list`, and none of jj's workspace bookkeeping
applies to it -- the isolated checkout ends up outside the VCS that owns the
repo.

Add the `worktree` entry to the git->jj map and a PreToolUse matcher on
EnterWorktree|ExitWorktree that exits 2 with the jj workspace commands on
stderr. The tool matcher replaces a `permissions.deny` entry in user
settings.json: it travels with the plugin and names the replacement command
instead of failing silently.

Read-only `git worktree list` is blocked along with the rest of the verb.
It cannot see jj workspaces, so its empty output reads as "no isolated
checkouts exist" when several do -- worse than a denial.

Verified by running the guard against `git worktree add ../feature` over
socket stdin and confirming both the denial and that the reason names
`jj workspace add`. The new checks fail against the 1.1.1 map.

Tests: 12 passing (bash-guard).

plugins/guards/hooks/test-bash-guard.py

@@ -60,6 +60,10 @@ r = run_guard(bash('git commit -m "hook test"'))
 check("git commit is denied", decision(r) == "deny", f"got {decision(r)!r}")
 check("denial names the jj equivalent", "jj describe" in reason(r), f"got {reason(r)!r}")
 
+r = run_guard(bash("git worktree add ../feature"))
+check("git worktree is denied", decision(r) == "deny", f"got {decision(r)!r}")
+check("denial names jj workspace", "jj workspace add" in reason(r), f"got {reason(r)!r}")
+
 r = run_guard(bash("git status"))
 check("read-only git is allowed", decision(r) != "deny", f"got {decision(r)!r}")