feat(workspace): attach the bound workspace's integration engine

Integrations are served by the local datamate engine — the same process the VS
Code extension spawns as `datamate start-stdio`. Altimate Code could reuse an
entry an IDE had already written, but could not acquire an engine on its own:
with no entry present it fell through to the hosted SSE endpoint, which runs in
multi-user mode and serves a DIFFERENT tool set (no connection validation, no
extension-bridge tools, server-side cwd). A terminal session in a bound project
therefore had either the IDE's tools or the wrong ones.

`workspace/engine-sync.ts` closes that gap with `ensure(sessionID)`, idempotent
per session and gated on the workspace pilot flag. Its rules, in order:

**Reuse.** A connected `datamate` MCP entry wins — that is an IDE-written or
previously persisted entry, and attaching to it is free. If it is down, what it
is decides what happens next. A URL entry is an IDE's in-process engine or the
hosted endpoint; neither can be revived from here, so with a binding and a
usable engine on PATH we spawn locally and report what was replaced. The IDE's
own config is never touched. A command entry that failed is retried once, then
reported — spawning a second engine beside a failing one is the duplicate-process
problem the single-gateway design exists to avoid.

**Opportunistic use, never an install.** A `datamate` on PATH whose `--version`
clears the floor is spawned as `datamate start-stdio --datamate <id>`, pinned to
the bound workspace and persisted to the project config so later sessions start
it at boot. With no engine present the user is told which workspace tools are
unavailable and how to install one; the CLI ships as a self-contained binary
with no Node runtime, so it must not pull one in.

**Never fall back to hosted on failure.** The local and hosted tool sets diverge
in both directions, so a silent fallback would change the workspace's declared
contract. A failed engine is reported, not routed around.

**Report what was declared but not delivered.** The engine intersects the
workspace allowlist with what it managed to build and says nothing about the
difference; this diffs declared keys against the tools that actually arrived and
surfaces the gap.

**First-turn readiness.** A turn resolves its tool list before the per-turn work
that starts the attach, so a session that spawned its own engine listed the
engine's tools one turn late — the model saw `datamate_manager` alone on the
first turn and the integration tools only from the second. The attach now starts
ahead of tool resolution and `whenAttached` gives it a bounded window, so those
tools make the first tool list. A cold attach measures ~6.5s (≈1s to probe
`--version`, ≈1s for the declared allowlist, ≈4.5s for the engine to boot,
handshake and build its tools), against a 15s cap set well clear of that and far
below MCP's own 30s connect timeout. Past the cap the turn proceeds and
`tools/list_changed` delivers the tools when they land. Unbound and disabled
sessions settle without I/O and wait for nothing.

`datamate_manager list-integrations` now hides extension-type integrations,
which are RPC into a live VS Code host and have no meaning on the CLI surface,
and reports how many it hid rather than pretending they do not exist.

Inert without a local binding. 21 unit tests cover the decision logic through
the `syncInternals` seams.

Author: ralphstodomingo

packages/opencode/src/altimate/api/client.ts

@@ -37,6 +37,11 @@ const DatamateSummary = z.object({
 const IntegrationSummary = z.object({
   id: z.coerce.string(),
   name: z.string().optional(),
+  // altimate_change start — catalog `type` (tool | mcp | code | api | extension).
+  // Extension-type integrations are RPC into a live VS Code host and have no
+  // meaning on the CLI surface; callers filter on this.
+  type: z.string().optional(),
+  // altimate_change end
   description: z.string().nullable().optional(),
   tools: z
     .array(

packages/opencode/src/altimate/tools/datamate.ts

@@ -138,11 +138,18 @@ async function handleList() {
 
 async function handleListIntegrations() {
   try {
-    const integrations = await AltimateApi.listIntegrations()
+    const catalog = await AltimateApi.listIntegrations()
+    // altimate_change start — extension-type integrations need a live VS Code
+    // bridge and cannot work from the CLI. Hide them from this surface (the
+    // workspace UI still offers them), but say how many were hidden rather than
+    // pretending they don't exist.
+    const integrations = catalog.filter((i) => i.type !== "extension")
+    const hidden = catalog.length - integrations.length
+    // altimate_change end
     if (integrations.length === 0) {
       return {
         title: "Integrations: none found",
-        metadata: { count: 0 },
+        metadata: { count: 0, hidden },
         output: "No integrations available.",
       }
     }
@@ -151,9 +158,17 @@ async function handleListIntegrations() {
       const tools = i.tools?.map((t) => t.key).join(", ") ?? "none"
       lines.push(`${i.id} | ${i.name} | ${tools}`)
     }
+    // altimate_change start
+    if (hidden > 0) {
+      lines.push(
+        "",
+        `(${hidden} extension-type integration${hidden === 1 ? "" : "s"} omitted — they require a live VS Code bridge and are not available from the CLI.)`,
+      )
+    }
+    // altimate_change end
     return {
       title: `Integrations: ${integrations.length} available`,
-      metadata: { count: integrations.length },
+      metadata: { count: integrations.length, hidden },
       output: lines.join("\n"),
     }
   } catch (e) {