revert: feat: add opencode.db cleanup and migration failure auto-recovery (#200)

[Svtter]

Reverts #200

PR was merged before resolving blocking AI review issues. Will re-land with fixes in a new PR.

[github-actions]

有条件合并 / CONDITIONAL MERGE

该 PR 移除了 cleanup-db 数据库清理和 SQLite 迁移自动恢复逻辑，代码改动干净一致，无残留引用。但存在一个经多 reviewer 交叉验证的阻塞前提条件。

阻塞项：

1. 移除 SQLite 迁移自动恢复逻辑（run-opencode.sh 中 duplicate column name 检测后删除重试）前，需要确认 opencode CLI 已不再产生该错误，否则用户将无警告地遇到硬失败。此问题被 quality reviewer 标为阻塞，performance reviewer 也独立指出了相同的担忧（建议保留该恢复逻辑），属于跨 reviewer 确认的可靠性回退风险。

建议项：

1. 在 CHANGELOG / release notes 中显式标注此变更，提醒自定义了 cleanup-db 输入的老用户该输入已被静默忽略。
2. 确认测试套件中是否有依赖 cleanup-db 的端到端测试需要清理。
3. 考虑在 opencode CLI 自身增加数据库大小管理逻辑，防止自托管 runner 上 opencode.db 无限增长导致性能下降。

---

📋 各 Reviewer 详细审查结果

quality

有条件合并 / CONDITIONAL MERGE

该 PR 移除了 cleanup-db 数据库清理功能和 SQLite 迁移自动恢复逻辑，代码层面的改动干净彻底：所有相关文件（action.yml、cleanup-db.sh、run-opencode.sh、README 文档）均已同步删除，无残留引用，无语法错误。

阻塞项：

1. PR 未解释移除这两个功能的前提条件。需确认 opencode CLI 已不再产生 duplicate column name 的 SQLite 迁移错误，或者 opencode 内部已自行处理此类问题。如果仍存在此问题的可能性，则直接移除自动恢复逻辑会导致用户无警告地遇到硬失败，属于行为回退。

建议项：

1. 建议在 CHANGELOG / release notes 中显式标注此变更，提醒自定义了 cleanup-db 输入的老用户，该输入已被静默忽略（composite action 不会对未知输入报错）。
2. 建议确认测试套件中是否有依赖 cleanup-db 功能的端到端测试需要一并清理或适配。目前搜索未见任何测试引用，但建议 double-check CI 中的测试覆盖率。

security

安全无虞 / SECURE

安全分析摘要

此 PR 纯粹是删除代码，删除了以下功能：

• cleanup-db 输入参数与对应的 cleanup-db.sh 脚本（SQLite 数据库大小阈值清理）
• run-opencode.sh 中的 SQLite 迁移失败自动恢复逻辑（检测 duplicate column name 后删除数据库重试）

所有删除的代码本身是可靠性/运维增强逻辑，不涉及安全控制（如认证、授权、加密）。移除这些功能不会引入新的攻击面或安全漏洞。PR 不包含任何新的输入处理、网络请求、外部数据引入或权限变更。

阻塞项：无

建议项：无

performance

性能有疑虑 / CONCERNS

此 PR 删除了两个功能：opencode.db 清理脚本和 SQLite 迁移失败自动恢复逻辑。从性能角度看：

阻塞项：无

建议项：

1. 移除 cleanup-db.sh 后，opencode.db 在自托管 runner 上可能无限增长。大型 SQLite 数据库会导致查询性能下降、磁盘 I/O 增加，并在迁移时占用更多内存。建议将数据库大小管理逻辑下沉到 opencode CLI 自身，或保留一个轻量级的清理机制在 action 层。

2. 移除 run-opencode.sh 中的迁移恢复逻辑（duplicate column name 自动删除重试）后，一旦 SQLite 迁移失败，整个 run 直接退出，没有自动修复路径。这虽更偏向可靠性而非性能，但失败重试的开销（删除文件后立即重试）几乎为零，建议考虑保留。

3. 删除的 cleanup-db.sh 本身每次运行会执行一次 stat 检查文件大小，该操作开销极低（O(1) 文件元数据读取）。移除它的收益（节省一次 stat 调用）远小于可能带来的数据库膨胀风险。如果确定要从 action 层移除，建议在 opencode CLI 的启动路径中增加类似的数据库大小检查和自动清理逻辑。

architecture

架构合理 / SOUND

该 PR 清理了两个原本属于 workaround/hack 性质的机制：shared/cleanup-db.sh 和 run-opencode.sh 中的 SQLite 迁移恢复逻辑。整体上简化了架构。

架构分析

• 耦合：移除后 github-run-opencode 不再依赖 shared/cleanup-db.sh。该脚本名义上在 shared/ 实际只被一个 action 使用，从未被复用，放在 shared/ 本身就是耦合误导，删除后反而正确。
• 模块放置：shared/cleanup-db.sh 仅供单一消费方却放在共享目录，位置不合理。删除后消除了这一命名/位置不一致。
• 分层：迁移恢复逻辑混入 run-opencode.sh 的通用重试循环中，属于数据库层关注点侵入执行层。删除后 run-opencode.sh 职责更加单一——只负责运行 opencode 并根据输出做重试。
• 接口设计：cleanup-db input 暴露了底层实现细节（DB 文件大小阈值）给 action 用户，属于抽象泄露。移除后接口更干净。
• Shotgun surgery：改动集中在 cleanup-db.sh、action.yml、run-opencode.sh 及相关 README，范围适度且一致，无散弹式修改。
• 一致性：恢复逻辑和 DB 清理都是应对 SQLite 迁移问题的临时解决手段，不属于项目核心架构模式。移除后代码更符合原有"轻量 wrapper action"的设计定位。

阻塞项：无

建议项：无

[Svitter]

P3 — already merged (888f2cc).

Clean revert of #200: 6 files, symmetric 78-line reversal, net-zero diff from pre-#200 state (25cf539). No stale references to cleanup-db / migration_recovery remain anywhere in the tree.

No blocking issues, no inline findings. Thanks for the quick revert.