Remote Control header shows wrong repo (falls back to first githubRepoPaths key) for --spawn=worktree sessions

Summary

In Remote Control, the session header's repo subtitle is mis-resolved for sessions started with claude remote-control --spawn=worktree. Instead of the session's actual repository, it shows the first key of ~/.claude.json githubRepoPaths (the first repo ever opened on the machine). As a result, every worktree-spawned session across all environments shows the same wrong repo.

Environment

• claude-code 2.1.177
• Linux (headless VM), Remote Control with multiple named environments, each launched from its own repo:

claude remote-control --name <env> --spawn=worktree (cwd = that repo root)

• Multiple repos cloned locally; githubRepoPaths example:

``json
{ "pearlzzi98/kakao_chatbot": ["/home/u/projects/kakao_chatbot"],
"pearlzzi98/devbox": ["/home/u/projects/devbox"] }
``

Repro

1. Start RC environments for several repos, each --spawn=worktree from its own repo root.
2. From the mobile app, open the devbox (or devlog) environment and start a new session.
3. The session runs in a bridge worktree: <repo>/.claude/worktrees/bridge-cse_* (git origin = correct repo).
4. Observe the header repo subtitle.

Expected: pearlzzi98/devbox (the session's actual repo, e.g. from the cwd's git origin).
Actual: pearlzzi98/kakao_chatbot — the first key of githubRepoPaths. Same wrong label for every environment, including repos not present in githubRepoPaths at all.

Investigation findings

We instrumented githubRepoPaths and observed the header on create vs reconnect:

• Create-time resolution can match the worktree path: after registering the worktree cwd under the correct repo key (via a SessionStart hook that wins the race — confirmed by timestamps), the header shows the correct repo at session creation.
• Reconnect/re-entry resolution differs: on leaving and re-entering the session, the label reverts to the first key, even though the worktree path and the repo root are exact-registered under the correct key. So the reconnect path ignores exact-match on both the worktree subpath and the repo root, and falls back to the first key.
• The first key is not stably controllable: manually reordering githubRepoPaths to put the correct repo first makes the label flash correct, then the running client rewrites the order back (primary/MRU), and the label settles on the wrong repo again.
• git remote origin of the cwd is not used for the subtitle (otherwise the correct repo would show).

Net: there is no local workaround via githubRepoPaths, because a single global "first key" cannot represent the distinct repo of each environment, and the reconnect resolver ignores per-path registration.

Suggested fix

Resolve the RC header repo from the session's working directory (git remote of cwd, walking up through git worktrees to the main repo), consistently at both create and reconnect — instead of falling back to the first githubRepoPaths key.

Impact

Cosmetic but persistent: the repo subtitle is wrong for all worktree-spawned RC sessions, so it can't be used to tell environments apart. (We currently disambiguate via a manual session-title prefix.) Possibly related: #62754, #66981.