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/scripts/_gitea.py

@@ -7,8 +7,10 @@ query quirks. It does NOT know what an issue is: no sections, no acceptance
 criteria, no type taxonomy. Payload shapes come from map.py; the domain model
 lives one layer further out in skills/issue/scripts/issue.py.
 
-Login: resolved from .claude/settings.local.json (env.GITEA_LOGIN), walking up
-from CWD — the same file /tea:auth writes and the tea-guard hook reads. No
+Login: the operator's pin from .claude/settings.local.json (env.GITEA_LOGIN).
+Where that file is searched for is NOT written here — skills/auth/scripts/pin.py
+owns the search order, and the tea-guard hook imports the same module, so `tea`
+and the scripts can never disagree about which login a directory runs under. No
 script here accepts a login argument: the operator's pin is the only identity
 they will use. No pin -> exit with a pointer to /tea:auth.
 
@@ -100,29 +102,32 @@ PAYLOAD_ROOT = payload_root()
 # --------------------------------------------------------------------------
 # login
 # --------------------------------------------------------------------------
+# Borrowed from the identity layer, not reimplemented: `pin.find_pin` is the
+# single written copy of the search order, and the tea-guard hook calls the
+# same function. When the two had a copy each, a git worktree got a hook that
+# resolved the pin and a transport that did not — in the same directory.
+#
+# Note the asymmetry with PAYLOAD_ROOT above, and with issue.store_root: those
+# are anchored on their own file, this is not, and both are right. 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 installed
+# outside any repository must not answer it from its own directory. See the
+# module docstring in pin.py.
 
-def find_pin(start_dir=None):
-    """Walk up from start_dir; return the login from the first
-    .claude/settings.local.json carrying a non-empty env.GITEA_LOGIN."""
-    d = os.path.abspath(start_dir or ".")
-    while True:
-        p = os.path.join(d, ".claude", "settings.local.json")
-        if os.path.isfile(p):
-            try:
-                with open(p) as f:
-                    v = (json.load(f).get("env") or {}).get("GITEA_LOGIN")
-                if isinstance(v, str) and v.strip():
-                    return v.strip()
-            except Exception:
-                pass
-        parent = os.path.dirname(d)
-        if parent == d:
-            return None
-        d = parent
+_AUTH_SCRIPTS = os.path.abspath(
+    os.path.join(_HERE, os.pardir, os.pardir, "auth", "scripts"))
+if _AUTH_SCRIPTS not in sys.path:
+    sys.path.append(_AUTH_SCRIPTS)
+import pin  # noqa: E402
 
 
 def require_login():
-    login = find_pin(os.getcwd())
+    """The operator's pinned login, or exit pointing at /tea:auth.
+
+    No pin found is reported as exactly that. It stays a truthful message: the
+    fix for "the pin is somewhere this search does not reach" belongs in
+    pin.py, never in a hint here that sends the operator to pin it twice."""
+    login, _ = pin.find_pin()
     if not login:
         die("no login pinned (.claude/settings.local.json env.GITEA_LOGIN). Run /tea:auth.")
     return login