feat(engines): add opencode engine support

[yyi407609-droid]

• Add OpenCodeEngine implementing the Engine interface
• OpenCodeExecutor spawns opencode CLI with JSONL streaming
• OpenCodeStreamProcessor transforms opencode events into CardState
• Windows path resolution with OPENCODE_EXECUTABLE_PATH env var support
• Add 'opencode' to EngineName type and BotConfigBase
• Add OpenCodeBotConfig for model/skipPermissions/extraArgs settings

[floodsung]

Triage 路过 — 这个 PR 看起来设计合理（实现了 Engine 接口，与 Claude/Kimi/Codex 的结构对齐），但有几点想请你补充再交给维护者 review：

1. CI 没有 run（statusCheckRollup 为空）。能否在本地跑一遍 npm run build、npm test、npm run lint 并把输出贴到 PR 描述里？这是仓库 CLAUDE.md 的 'Feature Completion Workflow' 要求，体量较大的 PR（+448 行）尤其需要这一步。

2. Test plan：PR 描述里没有手动测试步骤。在哪些场景下 e2e 测过？例如：bots.json 配 engine: "opencode" → 在 Feishu 发消息 → opencode CLI 拉起 → 消息卡片正常推送 → 多轮上下文保留。

3. opencode session continuity：opencode CLI 是否支持类似 Claude/Codex 的 session resume？stream-processor.ts / executor.ts 里看有没有 session ID 提取/复用的逻辑，需不需要在 session-manager 里加一份 opencode 分支？

4. README / CLAUDE.md 更新：CLAUDE.md 的 'Prerequisites' 部分目前列了 Claude/Kimi/Codex 三个引擎及其安装方法，opencode 引擎也建议加上一节。

补充后会更容易推进 review/合并。同时也欢迎留言 @floodsung 直接 ping 维护者。

[floodsung]

Thank you for the engine contribution — opencode is a reasonable addition to the engine roster. There are a few structural issues to fix before this can merge:

1. The custom OpenCodeStreamProcessor never gets used

The bridge (src/bridge/message-bridge.ts:10,692,1082 and src/bridge/output-handler.ts:5) hard-codes import { StreamProcessor } from '../engines/index.js' and instantiates it directly. Introducing StreamProcessorLike in types.ts doesn't help because no caller uses the union. So OpenCodeStreamProcessor is dead code — every stream goes through Claude's StreamProcessor regardless of engine.

The codex engine handles this correctly: it just reuses StreamProcessor (see src/engines/codex/index.ts:4,19). Please follow that pattern:

• Delete src/engines/opencode/stream-processor.ts
• Have OpenCodeEngine.createStreamProcessor() return new StreamProcessor(userPrompt)
• Remove StreamProcessorLike from types.ts

2. Image path extraction is non-functional

extractImagePaths() in your stream processor returns Array.from(this._imagePaths), but _imagePaths is never populated anywhere. Output images won't be sent to users. (This goes away naturally once you delete the file per item 1 — Claude's StreamProcessor already handles this.)

3. Tool-call tracking targets events that don't exist

stream-processor.ts:31-44 looks for block.type === 'tool_use', but the JSONL translator (jsonl-translator.ts:5-26) shows opencode doesn't emit those — so toolCalls always stays empty. Same fix: delete the file, reuse Claude's processor.

4. Hardcoded Windows paths are dead code

executor.ts:24-36 lists hardcoded paths with literal <USER> placeholders, then falls through to where opencode / which opencode resolution that would have worked anyway. The hardcoded list is unreachable / wrong. Please remove it and rely on PATH lookup + the OPENCODE_EXECUTABLE_PATH env var.

5. Hardcoded default model (minimax-cn-coding-plan/MiniMax-M2.5-highspeed) at executor.ts:74

Document why this default was chosen, or pull it into src/config.ts as an overridable default. As-is, if this model is deprecated upstream, every opencode bot breaks until the PR author updates the source.

6. No CI runs

PR is from 4/26 and has no CI checks reported. Please rebase onto main — that should trigger workflows and let us see the build/test/lint result.

Maintenance note: third-party CLI engines come with ongoing risk (CLI format changes, model deprecation, auth flow shifts). Worth confirming opencode is actively maintained before we commit to supporting it.

Once items 1, 2, 3, 4, 6 are addressed (5 is nice-to-have), this should be straightforward to merge.