fix(server): tell multi-repo agents which repos are in the project

[dotrahat]

In a multi-repo project, the agent often isn't told which repos are in the project, so it searches the workspace folder for them. Details are in #309.

Fix

This is option A from #309. The runtime instructions now list the project's repos. In an isolated worktree run, they list the worktrees. The list is added in the same sessions that get #307's path block. For a project whose .code-workspace is in the home folder, the model sees:

<project_repositories>
This project's repositories are:
- /home/<user>/<repo-1>
- /home/<user>/<repo-2>
- /home/<user>/Downloads/<repo-3>
- /home/<user>/<repo-4>
- /home/<user>/<repo-5>
The working directory, /home/<user>, is the project's workspace folder, not a repository. Other repositories under it are not part of this project, so there is no need to search it for more.
</project_repositories>

The last sentence is left out when the working directory is one of the repos. To tell these cases apart, multi-repo sessions now also receive the full repo list, in a new optional repoRoots field on ProviderSessionStartInput.

Codex gets the same block through additionalContext. Codex caps each entry at 1,000 tokens, which it counts as 4 bytes per token. In the #309 project, the entry Codex received was 3,086 bytes.

Testing

• Unit tests pass, including a new reactor test for worktree runs. The full suite passes too, except for 24 git tests. Those fail the same way on multi-repo-workspaces without this change.
• I asked "Give me list of repos that are part of this project" in the Multi-repo sessions don't tell the agent which repos are in the project when the repos are inside the workspace root #309 project. Claude Opus 5.5, Codex (GPT-6 Luna) and Gemini 3.8 Flash (Antigravity) each listed the five repos without using any tools. I didn't test Cursor, Grok or OpenCode.
• In a new-worktree run of a two-repo project, Claude, Codex and Gemini each listed the two worktrees without using any tools. The logs for Claude and Codex show the "workspace folder" sentence was left out. Antigravity doesn't log the prompt.
• I also tried a project with a non-git docs/ folder listed in its .code-workspace. Asked whether docs is part of the project, Claude checked the workspace file and said docs is in the workspace but isn't a repo.

Fixes #309

Model: Claude Opus 5.5, harness: Claude Code.

[LoganRupe]

Thanks for picking this up so quickly, and for testing it across providers. The Codex write-up is a good catch too. I wouldn't have spotted that newer models were skipping our instructions on this branch.

I checked out the branch: the tests pass and the server typecheck is clean. Two things before I merge:

1. Non-git folders. WorkspaceFile.ts only keeps folders that have a .git in repoRoots. So if a .code-workspace lists a plain folder like docs/, the last sentence tells the model it isn't part of the project. "Folders under it that are not listed above" can also read as covering api/src inside a listed repo. Could you narrow it to something like "Other repositories under it are not part of this project, so there is no need to search it for more"?

2. Codex. Rather than leave the merge steps in the PR body, I'm rebasing multi-repo-workspaces onto main now, so fix(server): newer Codex models get T3 Code's instructions again pingdotgg/t3code#13547 will be on the branch. Once that's pushed, could you rebase onto it and make the two Codex changes you described (multiRepo into buildCodexAdditionalContext, and the test reading additionalContext.t3_code_runtime.value)? That way the PR carries its own fix, and a test catches it if Codex ever loses the block.

I'll comment here once the branch is updated.

[LoganRupe]

multi-repo-workspaces is now rebased onto main, so pingdotgg#13547 is on the branch. This PR will need a rebase onto it, and GitHub shows it as conflicting until then.

One change from what I asked earlier: I had to resolve the #307 commit against pingdotgg#13547 during the rebase. Both Codex changes you described are already on the branch. multiRepo goes into buildCodexAdditionalContext, and the multi-repo test reads additionalContext.t3_code_runtime.value. So for Codex you only need to carry your MultiRepoWorkspace type through that call instead of the boolean. The narrower "not part of the project" wording is still the one open item.

[dotrahat]

Thanks, Logan. Both are done in ba234a6:

1. The sentence now reads: "Other repositories under it are not part of this project, so there is no need to search it for more." It no longer rules out plain folders like docs/.
2. I rebased onto the updated multi-repo-workspaces. The Codex path now carries the MultiRepoWorkspace through buildCodexAdditionalContext, and the Codex test checks that the repo list reaches additionalContext.t3_code_runtime.value.

I also added a reactor test for worktree runs, fixed a few code comments so they match when the block is added, and updated the PR description to take out the merge steps.