feat(opencode): add OpenCode as a third harness alongside Codex/Claude

[d180]

Summary

• Add OpenCode as a third harness alongside Codex and Claude (issue Support OpenCode #9): local opencode serve process management, an HTTP client, event/part mapping, and setup wizard + transcript discovery integration.
• Add live-progress narration and hang detection for OpenCode runs, polling OpenCode's own SQLite store while a run is in flight. This works around a confirmed, currently-open upstream OpenCode bug where tool calls (glob/read/bash) have no internal timeout and can hang forever.
• Change OpenCode's harness.model config validation from a fixed allowlist to a provider/model shape check, since OpenCode is a router that accepts any provider the user has authenticated — unlike Codex/Claude, which genuinely only offer a fixed handful of models and keep their allowlists.
• De-duplicate append_event/emit_result, which had drifted into three separate copies across the Codex/Claude/OpenCode harnesses, into one shared module.
• Fix a real Windows bug found during review: start_opencode_server() never resolved the opencode executable through PATH/PATHEXT, so an npm-installed shim would pass check()'s version probe but fail every real run.

Why

OpenCode was the one harness planned but not yet built (tracked in issue #9). Building it surfaced a real reliability gap (OpenCode's tool layer can hang indefinitely with no error), which needed a fix beyond just wiring up the adapter, or the harness would be unusable on any real repo.

Verification

uv run pytest        # 482 passed
uv run ruff check .  # All checks passed
uv build --out-dir dist   # both wheel and sdist built
uvx twine check dist/*    # both PASSED

Also live-tested end-to-end against a real project and a real opencode serve instance (not just fixtures): init and garden both completed cleanly with a healthy resulting wiki (codealmanac health reports zero orphans/dead refs/broken links).

Docs and wiki

• README/docs updated if user-facing behavior changed.
• .almanac/ wiki updated if an implementation decision, workflow, invariant, or gotcha changed.
• Not applicable.

Notes for reviewers

• Known upstream OpenCode issue this PR works around, not fixes: OpenCode's tool-execution layer (glob/read/bash/etc., including tools run inside sub-agents it spawns via its task tool) has no internal timeout, so a bad or over-broad tool call can hang a run forever with no error from OpenCode itself — reproduced live 3 times during this work. This is a confirmed, currently-open upstream bug: Glob tool execute has no timeout — hangs indefinitely when ripgrep scan is slow anomalyco/opencode#33541 (Glob tool execute has no timeout — hangs indefinitely when ripgrep scan is slow anomalyco/opencode#33541) ("Glob tool execute has no timeout"), Tool and task execution can hang indefinitely with no timeout anomalyco/opencode#20096 (Tool and task execution can hang indefinitely with no timeout anomalyco/opencode#20096), shell tool stays status=running indefinitely after subprocess exits — pipe FD leak in spawn anomalyco/opencode#29294 (shell tool stays status=running indefinitely after subprocess exits — pipe FD leak in spawn anomalyco/opencode#29294), Bug: Glob tool hangs indefinitely with chutes provider anomalyco/opencode#2102 (Bug: Glob tool hangs indefinitely with chutes provider anomalyco/opencode#2102). If you see a run fail with an error like OpenCode's "glob" tool call has been stuck for 240s+ with no response (session ses_...) — this is a known upstream OpenCode reliability issue (...), not specific to this run., that's this — the watchdog in integrations/harnesses/opencode/progress.py caught it and killed the run rather than hanging indefinitely; it is not a bug in this codebase, and there's nothing further to debug on our side beyond confirming the stuck tool/session in the error message.
• Known wiki gap, not yet fixed: almanac/decisions/controlled-model-catalog.md is an accepted decision doc stating CodeAlmanac never lets users type an arbitrary provider model — this PR's OpenCode shape-validation change contradicts that for the OpenCode harness specifically. almanac/architecture/agent-runs/provider-adapters.md also still only describes Codex and Claude. Both need an update (either carving out an explicit OpenCode exception or superseding the decision) before this is fully wiki-consistent. Flagging rather than silently leaving stale.
• Residual, disclosed risk: ~/.local/share/opencode/opencode.db as OpenCode's Windows storage path is inferred from the macOS spike, never verified on an actual Windows machine. Degrades gracefully if wrong (sync finds zero transcripts, no crash), but it's an open item, not a closed one.
• Full build history (4 plan + 5 fixes docs) is under docs/plans/2026-07-0{7,8,9}-opencode-harness-*.md if you want the slice-by-slice reasoning instead of just the diff.

Closes #9