[Bug]: orca tab create ignores ORCA_WORKTREE_ID and silently uses the UI-active worktree when cwd is not in a managed worktree #37899

Summary

orca tab create (and probably other worktree-scoped browser commands) decides the target worktree only from the caller's current directory. If the directory is not inside an Orca-managed worktree, the CLI does not fail. It silently opens the tab in whichever worktree is currently active in the Orca window. The ORCA_WORKTREE_ID / ORCA_WORKSPACE_ID variables that Orca exports into agent terminals are ignored. An agent that runs cd /tmp && orca tab create ... therefore puts its tabs in an unrelated repo, which changes with whatever the user is looking at.

Version

Orca 1.4.247 (orca --version), macOS, Orca desktop with local runtime.

Steps to reproduce

1. Open an Orca terminal in worktree A (here: /Users/me/GitHub/personal). The shell has ORCA_WORKTREE_ID=<repoId>::/Users/me/GitHub/personal.
2. Run cd /tmp && orca worktree current --json. It fails: No Orca-managed worktree contains the current directory: /private/tmp.
3. Run cd /tmp && orca tab create --url about:blank --json, then orca tab list --json and read worktreeId of the new tab.
4. Change the active worktree in the Orca window to worktree B and repeat step 3.
5. Repeat step 3 from inside worktree A's directory, with the identity variables removed:
   env -u ORCA_WORKTREE_ID -u ORCA_WORKSPACE_ID -u ORCA_TERMINAL_HANDLE -u ORCA_TAB_ID -u ORCA_PANE_KEY -u ORCA_AGENT_PANE orca tab create --url about:blank --json

Observed

So the cwd decides. The environment is not used. When the cwd is unmanaged, the choice depends on UI state.

Expected

One of these:

• Use ORCA_WORKTREE_ID (or ORCA_WORKSPACE_ID) when the cwd is not in a managed worktree. A terminal that Orca itself started knows which worktree it belongs to.
• Or fail with a clear error, as orca worktree current already does, and tell the caller to pass --worktree.

A silent fallback to the active worktree is the worst choice for agents. The tabs appear in a repo the user did not expect, and nothing reports it.

Workaround

Pass --worktree "id:$ORCA_WORKTREE_ID" explicitly. With it, the tab lands in the right worktree from any cwd (tested from /tmp).

Impact

Agents often cd to a scratch directory such as /tmp before running scripts. Eight tabs of one task ended up in a different repo's workspace. The user has seen this several times. It is hard to notice because the CLI output does not name the worktree.

Possible fix

Resolve the worktree in this order: explicit --worktree, then cwd inside a managed worktree, then ORCA_WORKTREE_ID, then error. Also print the resolved worktree in the tab create result.