Pick a nested git repo when the project root isn't a git repo

[scriptease]

Problem

If a project's root directory is not a git repository, the git actions control shows only one option: Initialize Git. That runs git init at the project root.

That's wrong for two common layouts:

1. Monorepo without git at the root. Several packages or services live side by side, and each one is its own git repo.
2. A folder of repos. For example ~/github/ containing repo-a/, repo-b/, repo-c/, each with its own .git. You add the parent folder as the project so the agent can read and change several repos in one thread.

In both cases, initializing git at the root is not what you want. It would create a repo that contains other repos. Once you skip it, you lose the diff view, commit, push/PR actions, and checkpoints, even though the files the agent is editing are already inside a real git repo.

Proposal

When the project root is not a git repo, offer a Select repository option next to Initialize Git:

• Scan the project root for nested git repos: directories that contain .git (a directory, or a file for worktrees/submodules). Limit the depth, for example 2 or 3 levels, and skip node_modules and the like.
• Show them as a list of relative paths (repo-a, packages/api, ...).
• Picking one makes it the active git working directory for the thread. Diff, commit, push, PR, and branch actions all run against that repo.
• Show the active repo in the git control and let the user switch it or clear it. It is per thread, so two threads in the same parent folder can each target a different repo.

Heuristic default (optional)

People often open the first message with the folder they want to work in ("in repo-b, fix ..."), and agents tend to stay in one repo per turn. Two signals could preselect a repo:

• A path in the first user message that resolves to (or sits inside) one of the nested repos.
• The files the agent actually changes in the first turn, if they all belong to one nested repo.

This should suggest a repo, not silently switch to it. The user confirms, or it shows as the default that they can change.

Open questions

• Checkpoints: checkpoints are hidden git refs. Should they go into the selected nested repo, or stay disabled for non-repo roots? Using the selected repo seems natural, but edits outside it wouldn't be captured.
• Multiple repos changed in one turn: one active repo per thread keeps the model simple. Showing diffs across every touched repo would be nicer, but it's a much bigger change.
• Where the selection lives: per thread (my preference) or per project.
• Surfaces: web/desktop git control, plus mobile, which has the same git actions.

Why

Pointing the agent at a parent folder is the easiest way to work across related repos (a shared lib plus its consumer, frontend plus backend in separate repos). Today that setup costs you every git feature in T3 Code, or you have to create a pointless root repo.