feat(ssh): wave 1 — ExecBackend + computer data model + runtime threading

Wave 1 of transparent SSH support (parallel owner-agents on disjoint packages,
plus the orchestrator-authored kernel contract seam from wave 0):

- packages/wire: + Computer/ComputerEntry (read-only view over ~/.ssh/config
  Host aliases) + Workspace.defaultComputerId (string|null, null=local). Types
  only; 3 conformance tests.
- packages/exec-backend (NEW core extension): the ExecBackend abstraction
  (spawn + minimal fs surface) the bundled tools will program against instead
  of node:fs/child_process. LocalExecBackend wraps today's node calls
  (behavior-identical; node:fs-style .code errors). execBackendHandle +
  ExecBackendResolver (sync; computerId undefined -> local; set -> throws until
  the ssh package wires remote resolution in wave 5). 20 tests.
- packages/kernel (runtime only): thread computerId through dispatch.ts +
  run-turn.ts exactly as cwd is threaded (opaque, forwarded to
  ToolExecuteContext; absent = local = byte-identical to today). +2 tests.
- packages/conversation-store: computer (SSH alias) assignment + resolution
  mirroring cwd — WorkspaceRow.defaultComputerId + setWorkspaceDefaultComputerId
  + getComputerId/setComputerId/clearComputerId + getEffectiveComputer
  (override -> per-conv -> workspace default -> null/local). Fixes the 3
  Workspace literal sites the new required wire field broke. +18 tests.
- orchestrator: root tsconfig.json ref for exec-backend + bun install.

Verified: tsc -b EXIT 0, biome clean, 1592 vitest pass (was 1549, +43).
Refs: notes/ssh-support-plan.md (decisions §0.5/§13). No merge or push.

1 files changed, 48 insertions, 0 deletions

diff --git a/packages/exec-backend/src/extension.ts b/packages/exec-backend/src/extension.ts
new file mode 100644
index 0000000..c07b7a8
--- /dev/null
+++ b/packages/exec-backend/src/extension.ts
@@ -0,0 +1,48 @@
+import type { Extension, Manifest } from "@dispatch/kernel";
+import type { ExecBackend } from "./backend.js";
+import { localExecBackend } from "./local.js";
+import type { ExecBackendResolver } from "./service.js";
+import { execBackendHandle } from "./service.js";
+
+export const manifest: Manifest = {
+	id: "exec-backend",
+	name: "Exec Backend",
+	version: "0.0.0",
+	apiVersion: "^0.1.0",
+	trust: "bundled",
+	activation: "eager",
+	contributes: { services: ["exec-backend/resolver"] },
+};
+
+/**
+ * The resolver provided by this extension.
+ *
+ * - `computerId` undefined → `LocalExecBackend` (today's local behavior).
+ * - `computerId` set → throws. Remote execution is wired by `host-bin` + the
+ *   `ssh` package in a later wave (`SshExecBackend` implements the same
+ *   `ExecBackend` interface). For now only the local path exists — failing
+ *   loudly here is safer than silently running locally when remote was requested.
+ */
+function resolveBackend(computerId?: string): ExecBackend {
+	if (computerId === undefined) return localExecBackend;
+	throw new Error(
+		`Remote execution (computerId="${computerId}") is not yet configured. ` +
+			"The SSH backend will be wired by the ssh package.",
+	);
+}
+
+/**
+ * Factory: create the `exec-backend` core extension.
+ *
+ * `activate` provides the local-only `ExecBackendResolver` via the typed
+ * service handle. Remote resolution is added in a later wave.
+ */
+export function createExecBackendExtension(): Extension {
+	return {
+		manifest,
+		activate(host) {
+			const resolver: ExecBackendResolver = resolveBackend;
+			host.provideService(execBackendHandle, resolver);
+		},
+	};
+}