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>

AGENTS.md

@@ -24,11 +24,17 @@ skills/page     DOMAIN     what a page tree is: title <-> path, order, the index
       ▲                    offline — no tracker, no network, stdlib imports only
       │ imports
 skills/sync     BRIDGE     map.py     md <-> Gitea issue JSON, pure, no I/O
-                           _gitea.py  login pin, tea api, pagination, filters
+                           _gitea.py  tea api, pagination, filters, payloads
 skills/wiki     BRIDGE     wikimap.py md <-> Gitea wiki JSON, pure, no I/O
                            transport is _gitea.py — there is no second one
-skills/use      REFERENCE  tea CLI docs for everything that is not an issue
+      │ imports
+      ▼
 skills/auth     IDENTITY   pin the login the whole tracker side runs under
+      ▲                    pin.py  where the pin is and how it is found —
+      │ imports            imported by _gitea.py AND by hooks/tea-guard.sh
+hooks/tea-guard            so `tea` and the scripts cannot disagree
+
+skills/use      REFERENCE  tea CLI docs for everything that is not an issue
       ▲
       │ calls
 agents/         EXECUTION  tea-runner: runs the scripts, reports a receipt
@@ -51,6 +57,8 @@ If a tracker concept (issue number, login, HTTP call, label color, `sub_url`,
 ## Repo layout
 
 - `skills/auth` — pin the Gitea login used by `tea` (`/tea:auth`)
+  - `scripts/pin.py` — the one written copy of the pin's location and search
+    order (see "The login pin" below); stdlib, no subprocess, no network
 - `skills/issue` — issues as units of work (`/tea:issue`), entirely offline
   - `references/format.md` — canonical issue format; single source of truth
   - `scripts/issue.py` — domain module: slug identity, parse/render, validation,
@@ -63,8 +71,8 @@ If a tracker concept (issue number, login, HTTP call, label color, `sub_url`,
   - `scripts/issue_index.py` — rebuild `tmp/issues/INDEX.md`
 - `skills/sync` — move issues between the local store and Gitea (`/tea:sync`)
   - `scripts/map.py` — md ↔ Gitea JSON, pure, no I/O; label colors live here
-  - `scripts/_gitea.py` — transport: login pin, `tea api`, pagination, filters,
-    label ids, the remote-id map, `tmp/payload/`
+  - `scripts/_gitea.py` — transport: `tea api`, pagination, filters, label ids,
+    the remote-id map, `tmp/payload/`; the login comes from `auth/pin.py`
   - `scripts/pull.py`, `push.py`, `remote.py`, `comment.py`
   - `scripts/labels.py` — put the canonical `type/*` and `severity/*` set into a
     repository; reads the domain taxonomy, never the store
@@ -91,10 +99,40 @@ If a tracker concept (issue number, login, HTTP call, label color, `sub_url`,
   Delegating a single call costs more than running it inline — the win is the
   loop, the retry, and the error triage.
 - `hooks/` — PreToolUse hooks: `tea-guard` blocks or rewrites `tea` invocations
-  that don't use the pinned login; `agents-sync` keeps every directory canonical
-  (`AGENTS.md` real file, `CLAUDE.md` symlink to it)
+  that don't use the pinned login (resolving it through `auth/pin.py`);
+  `agents-sync` keeps every directory canonical (`AGENTS.md` real file,
+  `CLAUDE.md` symlink to it)
 - `tests/` — stdlib `unittest`, no third-party anything
 
+## The login pin
+
+`<project root>/.claude/settings.local.json` → `env.GITEA_LOGIN`, written by
+`/tea:auth` and read at call time. **The search order is written once, in
+`skills/auth/scripts/pin.py`**, and both callers import it: the transport
+(`_gitea.require_login`) and the `tea-guard` hook. Neither spells the path or
+the walk itself, and a test asserts they don't.
+
+Start directories, first hit wins: `$CLAUDE_PROJECT_DIR`, then a hint the
+caller supplies (the hook passes the Bash payload's `cwd`; a script passes
+nothing), then the current directory. Each one is searched up its parent chain,
+and then — only if that found nothing — up the parent chain of the **main
+working tree of any linked worktree** met on the way, reached by reading
+`gitdir:` out of a `.git` *file* and following `commondir`.
+
+**The pin is not resolved from `__file__`, and that asymmetry with
+`issue.store_root`/`page.store_root`/`_gitea.PAYLOAD_ROOT` is deliberate.**
+Where an installation keeps its files is a fact about the installation; whose
+login a project runs under is a fact about the project. A plugin installed
+outside any repository and pointed at somebody else's tree must not answer the
+second question from its own directory. So the search runs from the working
+directory upward — and reaches a worktree's main checkout by asking git.
+
+Two failures this replaces, both worth remembering: a git worktree is a
+*sibling* of the main checkout, so the untracked pin is not on its parent chain
+and the whole sync layer died there while `tea` in the same directory worked;
+and the cure it invited — `/tea:auth` inside the worktree — writes a second
+settings file into a directory that is deleted with the worktree.
+
 ## Tests
 
 ```bash