feat(opencode): native opencode integration — /mcpctl switcher, live project switching, footer indicator

Adds `mcpctl config opencode`, two opencode plugins and an `opencode` skills
sync target, so an mcpctl project can be switched from inside opencode's TUI
and the active one is visible at a glance.

Unlike `config claude` / `config prime-agent`, this writes NO MCP entry into
the host's config. opencode exposes an HTTP API for its own MCP registry
(`POST /mcp`), so the project is mounted through the running app:

  - the token stays in ~/.mcpctl/opencode-state.json (0600) instead of a
    mode-0644 opencode.json users paste into bug reports;
  - switching projects takes effect on the next turn, with no restart.

Inside opencode:
  /mcpctl         filterable project picker; switches live
  /mcpctl-status  active project, mount state, gateway URL
  /mcpctl-skills  re-sync this project's skills
  plus a `mcpctl:<project>` indicator in the prompt footer, next to the model
  name and one line above the token counter.

Design notes:
  - the MCP server is registered under a constant name, so tools keep a stable
    `mcpctl_*` prefix and opencode's per-request tool resolution shows the new
    project's tools by itself — no "your old tool names are dead" message to
    the model, unlike the pi extension;
  - an unchanged mount is never re-registered: mcp.add rebuilds the connection
    and mcplocal binds a gated project's unlocked state to that connection's
    mcp-session-id, so re-adding would re-lock a project begin_session had just
    opened;
  - the server plugin does not mount during setup — setup runs before the
    server accepts connections and mcp.add calls back into it, which hangs
    opencode on a blank screen before the TUI draws;
  - the switcher shells out to this CLI (--skip-plugin --skip-marker) so token
    minting, state and skills stay in one place;
  - no usable credential aborts non-zero with the state file untouched, so a
    failed switch leaves the previous project working rather than swapping it
    for a mount that 401s.

`skills sync --agent opencode` installs into ~/.config/opencode/skill (XDG
aware) with the same shared-tree semantics as pi and prime-agent. The
credential plumbing shared with `config prime-agent` is lifted to one place and
parameterised by agent rather than copied.

The plugin sources are embedded in the CLI (generated, freshness-tested) so an
installed binary with no source tree can provision them, and are typechecked
against the real @opencode-ai/plugin types.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BVwuCjuMoA13gmzYEfcrNP

scripts/generate-opencode-extension.ts

@@ -0,0 +1,62 @@
+#!/usr/bin/env node
+/**
+ * Generates `src/cli/src/config/opencode-extension.ts`, which embeds the two
+ * opencode plugin sources as string constants — mirroring how the pi extension
+ * (`pi-extension.ts`) and prime-agent's `/mcpctl` switcher
+ * (`prime-agent-extension.ts`) are embedded.
+ *
+ * Embedding matters: `mcpctl config opencode` must work from an installed
+ * binary that has no access to the source tree. The installed plugin files are
+ * this exact embedded source, so what the CLI ships is always what opencode
+ * runs.
+ *
+ * Regenerate after editing the plugin sources:
+ *   npx tsx scripts/generate-opencode-extension.ts
+ */
+import { readFileSync, writeFileSync, mkdirSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+
+const scriptsDir = import.meta.dirname;
+const root = join(scriptsDir, '..');
+const extDir = join(root, 'src', 'opencode-ext');
+
+const SERVER = readFileSync(join(extDir, 'mcpctl-opencode.ts'), 'utf-8');
+const TUI = readFileSync(join(extDir, 'mcpctl-opencode-tui.tsx'), 'utf-8');
+
+function embed(src) {
+  // JSON.stringify yields a quoted string literal we can inline directly.
+  return JSON.stringify(src);
+}
+
+const out = `/**
+ * Embedded source of the mcpctl opencode plugins — DO NOT EDIT BY HAND.
+ * Generated by \`npx tsx scripts/generate-opencode-extension.ts\` from
+ * \`src/opencode-ext/mcpctl-opencode.ts\` and
+ * \`src/opencode-ext/mcpctl-opencode-tui.tsx\`.
+ *
+ * \`mcpctl config opencode\` writes these verbatim into ~/.config/opencode/
+ * (and registers them), so an installed binary with no source tree can still
+ * provision a working opencode integration.
+ *
+ * The install file names differ from the source file names on purpose:
+ *   - the server plugin lands in opencode's auto-discovered \`plugin/\` dir,
+ *     where its basename is what shows up in \`opencode plugin list\`;
+ *   - the TUI plugin lands beside it in \`mcpctl/\`, referenced by path from
+ *     \`tui.json\`, and must keep a \`.tsx\` extension for opencode to transpile
+ *     its JSX.
+ */
+
+/** Install name of the server plugin, relative to ~/.config/opencode/plugin/. */
+export const OPENCODE_SERVER_PLUGIN_FILENAME = 'mcpctl.ts';
+
+/** Install name of the TUI plugin, relative to ~/.config/opencode/mcpctl/. */
+export const OPENCODE_TUI_PLUGIN_FILENAME = 'mcpctl-tui.tsx';
+
+export const OPENCODE_SERVER_PLUGIN_SOURCE: string = ${embed(SERVER)};
+
+export const OPENCODE_TUI_PLUGIN_SOURCE: string = ${embed(TUI)};
+`;
+
+mkdirSync(dirname(join(root, 'src', 'cli', 'src', 'config')), { recursive: true });
+writeFileSync(join(root, 'src', 'cli', 'src', 'config', 'opencode-extension.ts'), out);
+console.log('wrote src/cli/src/config/opencode-extension.ts');