Add OpenCode as a first-class CodeAlmanac harness client

[Ram-Pavith]

Summary

CodeAlmanac currently runs lifecycle operations (build / ingest / garden) through Codex and Claude harnesses (via Yoke). Users who work primarily in OpenCode cannot use their existing OpenCode install, auth, and model routing as the execution backend for Almanac jobs.

Problem

• There is no HarnessKind.OPENCODE path.
• Setup does not install OpenCode AGENTS / instruction guidance.
• Config does not accept OpenCode-style provider/model IDs (including nested paths like openrouter/z-ai/glm-5).
• README / doctor / setup wizard surfaces do not treat OpenCode as a supported client.

Desired outcome

Add OpenCode as a first-class native CLI harness (opencode run), not only a Yoke provider surface, so that:

1. Harness adapter — opencode run drives lifecycle agents with event streaming, session/transcript capture, and agents staged under product-owned local state (not the user repo).
2. Setup target — codealmanac setup can install OpenCode instruction blocks (and uninstall cleanly).
3. Config — harness.default = opencode and harness.model = provider/model (any valid OpenCode model id) validate correctly; switching default harness resets model to that provider’s default.
4. CLI / docs — setup wizard, parser choices, telemetry labels, and README document OpenCode alongside Codex and Claude.
5. Tests — unit coverage for adapter, model parsing/validation, setup wiring, and related surfaces.

Why native OpenCode (not Yoke)

OpenCode is a router: the TUI already connects to whatever the user configured (OpenRouter, OpenAI, Anthropic, Zen free models, custom OpenAI-compatible endpoints, etc.). A Yoke-mediated path would:

• Depend on AlmanacCode/Yoke publishing and pinning an OpenCode provider release before CodeAlmanac can ship.
• Tend toward a product-curated model catalog (or Yoke’s known surface), which inevitably lags what a given user’s OpenCode install can already run.
• Duplicate auth/session concerns OpenCode already owns.

Driving opencode run --model provider/model reuses the same CLI, credentials, and live model list as interactive OpenCode. Config validates id shape only (provider/model, nested segments allowed). Users can set e.g. openrouter/... and get the same models they see in the OpenCode TUI — no second allowlist, no wait for a Yoke OpenCode release.

Acceptance criteria

• HarnessKind.OPENCODE is registered and wired through composition / harness kinds.
• OpenCode adapter can check CLI readiness and run a lifecycle request.
• Setup installs/uninstalls OpenCode instructions without clobbering user content outside managed markers.
• Config accepts OpenCode provider/model ids (including OpenRouter nested paths) and rejects invalid / wrong-provider models for closed harnesses.
• README documents install/auth for OpenCode.
• Tests cover harness, models, and setup integration touchpoints.
• Transcript sync discovers/reads OpenCode SQLite sessions.
• Agents stage outside the target repo worktree.

Notes

Implementation: branch opencode-support / PR #42.