fix: resolve the login pin from a git worktree

`_gitea.require_login` walked up from CWD and nowhere else. A worktree is a
sibling of the main checkout, not a descendant, and `settings.local.json` is
untracked — so the pin lives in the main checkout only, is not on the
worktree's parent chain, and the whole tracker half of the plugin died there
with "no login pinned". In the same directory the guard resolved it fine,
because it had a search of its own: one order, written twice, disagreeing.

It is written once now, in skills/auth/scripts/pin.py, and both callers import
it — the transport and hooks/tea-guard.sh. $CLAUDE_PROJECT_DIR, then a hint the
caller supplies (the hook passes its payload's cwd), then the current
directory; each searched up its parent chain, and only if that finds nothing,
across into the main working tree of a linked worktree met on the way, reached
by reading `gitdir:` out of the `.git` FILE and following `commondir`. No
subprocess — a PreToolUse hook runs before every Bash call and must not fork to
answer this.

The search still starts at the working directory and never at `__file__`,
deliberately asymmetric with `issue.store_root` and `_gitea.PAYLOAD_ROOT`.
Where an installation keeps its files is a fact about the installation; whose
login a project runs under is a fact about the project, and a plugin pointed at
somebody else's tree must not answer that from its own directory. pin.py says
so in as many words, so the next reader does not "fix" the inconsistency.

Two consequences fall out of it. `/tea:auth` no longer has any reason to run
inside a worktree, so no second pin lands in a directory that is deleted with
the branch — the skill now says to write it beside the common `.git`. And the
scripts can run where the work is: the workaround the bug forced, cwd in the
main checkout, made push.py send that checkout's branch as `ref`, which is the
one thing `branch:` exists to record.

tests/test_login_pin.py holds both halves: the hop against a hand-built layout
and against a real `git worktree add`, a run from the worktree finding the
login, no pin anywhere still erroring, the scripts' own directory not becoming
a source, `ref` coming out as the worktree's branch, and the hook and a script
answering the same directory alike. Two mechanical checks keep the callers from
growing a second copy of the walk. Three existing fixtures now copy
skills/auth/scripts, which the transport imports.

Refs #24.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

skills/sync/SKILL.md

@@ -32,8 +32,13 @@ index.
 ## Scripts
 
 In `<skill-base-dir>/scripts/`. None of them take `--login`: they resolve the
-operator's pin from `.claude/settings.local.json` themselves, the same source
-the `tea-guard` hook reads. No pin → exit with a pointer to `/tea:auth`.
+operator's pin from `.claude/settings.local.json` through
+`skills/auth/scripts/pin.py` — the same *function* the `tea-guard` hook calls,
+not merely the same file, so a directory where `tea` works is a directory where
+these work. That includes a **git worktree**, whose untracked pin sits in the
+main checkout: the search crosses to it through the `gitdir:` in `.git`, and
+there is nothing to pin a second time. No pin anywhere → exit with a pointer to
+`/tea:auth`.
 
 | Script | What it does |
 |---|---|
@@ -312,6 +317,12 @@ a git repo no `ref` is sent and a warning names the issues that went up without
 one. Reading the branch is the only thing these scripts ask git for — they
 never check out, create, or write anything.
 
+The branch comes from the **current directory**, so run `push.py` from the tree
+the work is on. In a git worktree that is the worktree, and it is now also
+where the pin resolves from: the old workaround for the pin — run the scripts
+with cwd in the main checkout — sent the main checkout's branch as `ref`, which
+is the one thing `branch:` exists to record.
+
 ## What crosses the boundary, and what does not
 
 | domain | Gitea | note |