bug(runtime-host): `project add` silently changes an existing project's preferred location

[jsiu93]

What happened

maka runtime-host project add <second checkout of the same repository> reports locationCount: 2 and, as a side effect, makes that checkout the project's preferredPath. From then on every run --host --project <id> and every new Runtime Host Session for that project starts in the checkout that was just added. Re-adding the original path flips it back. Nothing in the command's output says the preferred location changed.

The catalog derives preferredPath from usage: it sorts the project's available locations by lastUsedAt and takes the newest. Registration writes the registration timestamp into the added (or re-added) location, so registering counts as using. Runtime Host project resolution then hands that derived path to Session creation.

The CLI TUI makes this easy to hit without noticing. It starts without creating a Session; the first prompt calls preparePrompt(), which creates the Session lazily, and the Host resolves the project's preferredPath at that moment. Add another checkout between launching the TUI and the first prompt, and the Session lands in the other checkout while the status line still names the one you launched in. Sessions that already exist keep their cwd; only new ones move.

--cwd is rejected with a remote Runtime Host, so CLI callers have no explicit way to choose a location; re-adding a path is the only lever, and it is a silent one.

Expected: project add registers a location without changing where project-targeted Sessions start. Selecting the new path should be an explicit choice.

How to reproduce

1. Create a Git repository and a linked git worktree of it.
2. Start a Runtime Host with a fresh root.
3. maka runtime-host project add <repository> --root <host-root>
4. maka runtime-host project add <worktree> --root <host-root>
5. maka runtime-host project list --root <host-root>: two locations, preferredPath is the worktree.
6. Run any project-targeted command that prints its cwd (or launch maka --host <profile> --project <id>, add the worktree before the first prompt, then send a prompt that runs pwd). It runs in the worktree. Re-adding the repository path moves subsequent Sessions back.

Environment

• Maka version or commit: 0.1.11 dev build; confirmed on origin/main at ce0e5931a
• OS and version: macOS 26.6.1 (25G76)
• Surface: CLI runtime-host project add, CLI TUI, Runtime Host
• Node.js v22.22.2, npm 10.9.7

Logs, screenshots, or additional context

Live, unfixed build, fresh Host root, the worktree deliberately named so it sorts before the repository (so lexical tie-breaking cannot mask the result):

project add <repository>    -> locationCount: 1
project add <aaa-worktree>  -> locationCount: 2
project list                -> preferredPath: .../aaa-worktree

Desktop depends on the current behavior in one place: opening a folder registers it and then creates a project-targeted Session, which must start in the folder that was opened. A fix has to keep that path intact. Location selection for run --host and location removal are separate follow-ups.

I have a fix with regression tests; PR to follow.