fix(worktrees): resolve the execution host at both worktree-create entry points (#18545)

Two entry points create the same workspace and disagreed about how to read its
host. `orca-runtime-create-managed-worktree.ts:63` resolved through
`getRepoSshConnectionId` and then normalized the row; the `worktrees:create` IPC
handler branched on raw `repo.connectionId`
(`register-worktree-create-handlers.ts:66-69`). So a repo naming its owner only
as `executionHostId: 'ssh:<target>'` created remotely through the runtime and ran
`git worktree add` on the client against a remote path through IPC (#11163).
Same repo, two entry points, different answers.

Both now take one route, resolved through the existing layer
(`getRepoExecutionHostId` -> #18296's `resolveGitRouteForHost`). No new resolver.

The row normalization on the `ssh` variant is kept, and it is a **workaround, not
the pattern**. `createRemoteWorktree` and its callees re-read `repo.connectionId!`
at five depths in `ipc/worktree-remote.ts` (1627, 1847, 1848, 1865, 2029), so the
resolved connection has to reach them through the field they already read. It
travels only as far as that object does — anything downstream that re-reads the
row from the store still sees the unnormalized one, and it cannot express the
`runtime:` refusal on its own. Proper fix, deliberately not done here: give that
pipeline an explicit connection parameter and delete `repo.connectionId!` from it
so every reader becomes a compile error, the technique #18307/#18325 used. That
is a change inside a 2800-line module plus its callers, and it wants its own PR.

Three answers that used to collapse into one, now distinct at both entry points:

- `executionHostId: 'ssh:*'` with no `connectionId` -> that SSH host (IPC used to
  create locally);
- `executionHostId: 'local'` with a surviving `connectionId` -> local, since a
  local row cannot nest an SSH namespace. This is what `getRepoSshConnectionId`
  and therefore the runtime sibling already answered; IPC used to go remote;
- `runtime:<env>` -> refused. Its worktree is created by that environment's own
  server and the SSH target on its repo row is that server's nested one,
  addressable only as (environmentId, targetId). The renderer already routes
  runtime-environment creates over `worktree.create` RPC rather than this IPC
  channel, so reaching either entry point with one is a routing mistake. Matches
  `workspace-cleanup-git-route` and `runtime-git-command-target`.

Folder-workspace creation is untouched on both sides: it is a registration, not a
filesystem create, so the route is resolved after that branch on the IPC side, and
on the runtime side only the agent trust write consumes it — where a `runtime:`
host now yields `null` instead of the nested target, so the write stops going to a
same-named target in this client's table.

No wire or persistence change: the normalized row is a local value passed to the
create pipeline, never stored, and `CreateWorktreeResult` is untouched.

src/main/runtime/orca-runtime-create-managed-worktree.ts

@@ -4,7 +4,8 @@ import type { RuntimeManagedWorktreeCreateArgs } from './runtime-managed-worktre
 import type { CreateWorktreeResult } from '../../shared/worktree/create-types'
 import { isTuiAgentEnabled } from '../../shared/tui-agent-selection'
 import { isFolderRepo } from '../../shared/repo-kind'
-import { getRepoSshConnectionId } from '../../shared/execution-host'
+import { resolveWorktreeCreateRoute } from '../worktree-create-execution-host-route'
+import { ExecutionHostNotDispatchableError } from '../providers/execution-host-provider-dispatch'
 import { createRuntimeFolderWorktree } from './runtime-folder-worktree-create'
 import { createRuntimeLocalManagedWorktree } from './runtime-local-worktree-create'
 import { prepareRuntimeLocalWorktreeSetup } from './runtime-local-worktree-setup'
@@ -57,10 +58,14 @@ export class OrcaRuntimeWithCreateManagedWorktree extends OrcaRuntimeWithGetWork
         draftStartup?.agent ??
         (requestedAgentEnabled ? requestedAgent : undefined))
     const effectiveDraftPaste = args.startupDraftPaste ?? draftStartup?.draftPaste
-    // Resolve the execution host once: SSH ownership has two spellings, and reading the raw
-    // `connectionId` field routes an `executionHostId: 'ssh:*'`-only repo down the local path,
-    // which runs `git worktree add` on the client against a remote path.
-    const sshConnectionId = getRepoSshConnectionId(repo)
+    // Resolve the execution host once, shared with the `worktrees:create` IPC entry point so the
+    // two cannot answer differently for the same repo. Reading the raw `connectionId` field routes
+    // an `executionHostId: 'ssh:*'`-only repo down the local path, which runs `git worktree add` on
+    // the client against a remote path.
+    const createRoute = resolveWorktreeCreateRoute(repo)
+    // `null` on a `runtime:` host is deliberate: its nested target is addressable only inside that
+    // environment, so the trust write must not go to a same-named target in this client's table.
+    const sshConnectionId = createRoute.kind === 'ssh' ? createRoute.connectionId : null
     if (isFolderRepo(repo)) {
       // A folder workspace is a registration, not a filesystem create, so it is host-agnostic —
       // except for the agent trust write, which must land on the host that will run the agent.
@@ -97,20 +102,21 @@ export class OrcaRuntimeWithCreateManagedWorktree extends OrcaRuntimeWithGetWork
     const lineageInput =
       args.lineage || args.comment ? { ...args.lineage, comment: args.comment } : undefined
     const lineageResolution = await this.resolveLineageForWorktreeCreate(lineageInput)
-    if (sshConnectionId) {
-      // Why normalize the row: the remote-create pipeline reads `repo.connectionId!` at every
-      // depth, so hand it the connection the resolved host actually names.
-      const result = await this.createManagedRemoteWorktree(
-        { ...repo, connectionId: sshConnectionId },
-        {
-          ...args,
-          activate: args.activate,
-          ...(effectiveStartup ? { startup: effectiveStartup } : {}),
-          ...(effectiveStartupFollowup ? { startupFollowup: effectiveStartupFollowup } : {}),
-          ...(effectiveCreatedWithAgent ? { createdWithAgent: effectiveCreatedWithAgent } : {}),
-          ...(effectiveDraftPaste ? { startupDraftPaste: effectiveDraftPaste } : {})
-        }
-      )
+    if (createRoute.kind === 'runtime') {
+      throw new ExecutionHostNotDispatchableError(createRoute.hostId)
+    }
+    if (createRoute.kind === 'ssh') {
+      // `createRoute.repo` carries the resolved connection in `connectionId`, because the
+      // remote-create pipeline still reads `repo.connectionId!` at every depth. See the workaround
+      // note in worktree-create-execution-host-route.ts.
+      const result = await this.createManagedRemoteWorktree(createRoute.repo, {
+        ...args,
+        activate: args.activate,
+        ...(effectiveStartup ? { startup: effectiveStartup } : {}),
+        ...(effectiveStartupFollowup ? { startupFollowup: effectiveStartupFollowup } : {}),
+        ...(effectiveCreatedWithAgent ? { createdWithAgent: effectiveCreatedWithAgent } : {}),
+        ...(effectiveDraftPaste ? { startupDraftPaste: effectiveDraftPaste } : {})
+      })
       const recordedLineage = this.recordCreatedWorktreeLineage(result.worktree, lineageResolution)
       this.emitWorktreeLifecycle({
         kind: 'created',