refactor(git): normalize rtk-prefix usage, add metadata.version

Two bundled fixes across the same nine skills, since both touch the
same files.

Issue #113: skill prose used rtk git and bare git inconsistently for
the same operations, with no stated rule for which applied where.
Executable instructed commands (a dispatch-table "Run" cell, a fenced
code-block procedure, an imperative step) now consistently use rtk
git; illustrative or referential mentions -- naming a flag's behavior,
quoting a doc heading, warning against an anti-pattern -- stay bare
git. Documented in the new plugins/git/README.md, scoped to this
plugin only: gitea-* skills talk to the server over MCP tools and
carry no git/rtk mentions at all.

Also the git-plugin slice of #127: metadata.version added to the
eight skills that lacked it. git-commits already had one and is
untouched.

Fixes: #113
Fixes: #127
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP

plugins/git/.apm/skills/git-worktrees/SKILL.md

@@ -8,6 +8,7 @@ description: >
   Not interactive multi-step git guidance -> `git-workflow`.
 
 metadata:
+  version: "1.0.0"
   category: git
   source_keys:
     - git-scm-worktree-docs
@@ -16,7 +17,7 @@ metadata:
 ## Gotchas
 
 - **A branch can be checked out in only one worktree at a time.** `git worktree add` on an already-checked-out branch fails; `--force` is the only override, so use it only deliberately.
-- **Never `rm -rf` a worktree directory.** That strands metadata in `$GIT_DIR/worktrees/`. Use `git worktree remove`, or `git worktree prune` afterwards.
+- **Never `rm -rf` a worktree directory.** That strands metadata in `$GIT_DIR/worktrees/`. Use `rtk git worktree remove`, or `rtk git worktree prune` afterwards.
 - **Submodules break worktree support.** A worktree containing submodules cannot be moved at all, and needs `--force` to remove.
 - **`extensions.worktreeConfig = true` is a one-way door.** Without it, `git config --worktree` errors; with it, that flag writes to the worktree's own `config.worktree` file, and `core.bare`/`core.worktree` are forced there too. It also breaks older Git. Leave it off unless per-worktree config is needed.
 
@@ -24,19 +25,19 @@ metadata:
 
 | Operation | Run |
 |---|---|
-| Create on a branch that already exists locally | `git worktree add <path> <branch>` |
-| Create on a new branch | `git worktree add -b <branch> <path>` |
-| Create on the branch named after the path basename | `git worktree add <path>` — checks that branch out if it exists, else creates it from HEAD |
-| Create and reset an existing branch to HEAD — discards its commits | `git worktree add -B <branch> <path>` |
-| Create a local branch tracking a remote one | `git worktree add --track -b <branch> <path> <remote>/<branch>` — always correct. `git worktree add <path> <branch>` expands to exactly this, but **only** under the conditions in `references/worktrees.md` |
-| Throwaway experiment, no branch | `git worktree add -d <path>` — detached HEAD |
+| Create on a branch that already exists locally | `rtk git worktree add <path> <branch>` |
+| Create on a new branch | `rtk git worktree add -b <branch> <path>` |
+| Create on the branch named after the path basename | `rtk git worktree add <path>` — checks that branch out if it exists, else creates it from HEAD |
+| Create and reset an existing branch to HEAD — discards its commits | `rtk git worktree add -B <branch> <path>` |
+| Create a local branch tracking a remote one | `rtk git worktree add --track -b <branch> <path> <remote>/<branch>` — always correct. `git worktree add <path> <branch>` expands to exactly this, but **only** under the conditions in `references/worktrees.md` |
+| Throwaway experiment, no branch | `rtk git worktree add -d <path>` — detached HEAD |
 | **Never** `git worktree add <path> <remote>/<branch>` | That ref resolves, so the shortcut never fires and you get **a detached HEAD, no branch, no upstream**. Commits there go unreachable once HEAD moves, and `git push` needs an explicit refspec. Use the tracking row above |
-| List | `git worktree list -v`, or `--porcelain -z` to parse |
-| Lock or unlock | `git worktree lock [--reason <str>] <path>` / `git worktree unlock <path>` |
-| Move | `git worktree move <from> <to>` |
-| Remove | `git worktree remove <path>` |
-| Prune stale metadata | `git worktree prune --dry-run`, then without the flag |
-| Repair after a manual move | `git worktree repair` — in the main worktree if *it* moved, or inside a linked worktree that moved. `git worktree repair <path>...` — from any worktree, naming each moved linked worktree's new path |
+| List | `rtk git worktree list -v`, or `--porcelain -z` to parse |
+| Lock or unlock | `rtk git worktree lock [--reason <str>] <path>` / `rtk git worktree unlock <path>` |
+| Move | `rtk git worktree move <from> <to>` |
+| Remove | `rtk git worktree remove <path>` |
+| Prune stale metadata | `rtk git worktree prune --dry-run`, then without the flag |
+| Repair after a manual move | `rtk git worktree repair` — in the main worktree if *it* moved, or inside a linked worktree that moved. `rtk git worktree repair <path>...` — from any worktree, naming each moved linked worktree's new path |
 
 If the operation needs anything the table does not carry — the full `add` flag
 table, orphan branches, sparse-checkout, locking for removable media, remote
@@ -48,7 +49,7 @@ Gates:
 
 - **`move`, `remove` — the main worktree cannot be moved or removed.** Only linked worktrees, the ones `git worktree add` created, are candidates.
 - **`add`, `move`, `remove` — escalate force flags one step at a time.** `-f` overrides a safeguard such as an unclean tree; `move` and `remove` need `-ff` on top of that when the worktree is locked. Confirm with the user before either — both discard state.
-- **`add` — lock at creation, not after.** `git worktree add --lock` is atomic, where add-then-`lock` leaves a window in which the worktree is unprotected.
+- **`add` — lock at creation, not after.** `rtk git worktree add --lock` is atomic, where add-then-`lock` leaves a window in which the worktree is unprotected.
 
 ## Step 2 — Report
 
@@ -61,6 +62,6 @@ worktrees:
     lock_reason: <reason or empty>
 ```
 
-Derive those fields from `git worktree list --porcelain -z`. For a single
+Derive those fields from `rtk git worktree list --porcelain -z`. For a single
 operation, report its outcome instead — `created: true`, `moved: true`,
 `removed: true`.